国外外贸网站大全,wordpress顶部菜单哪里设置,什么是平面设计 都包括哪些内容,网站推广途径和推广要点的案例讨论Java学习面试指南#xff1a;https://javaxiaobear.cn
1、集群角色
Leader#xff1a; 领导者。
事务请求#xff08;写操作#xff09;的唯一调度者和处理者#xff0c;保证集群事务处理的顺序性#xff1b;集群内部各个服务器的调度者。对于create、setData、delete…Java学习面试指南https://javaxiaobear.cn
1、集群角色
Leader 领导者。
事务请求写操作的唯一调度者和处理者保证集群事务处理的顺序性集群内部各个服务器的调度者。对于create、setData、delete等有写操作的请求则要统一转发给leader处理leader需要决定编号、执行操作这个过程称为事务。
Follower: 跟随者
处理客户端非事务读操作请求可以直接响应转发事务请求给Leader参与集群Leader选举投票。
Observer: 观察者
对于非事务请求可以独立处理读操作对于事务性请求会转发给leader处理。Observer节点接收来自leader的inform信息更新自己的本地存储不参与提交和选举投票。通常在不影响集群事务处理能力的前提下提升集群的非事务处理能力。
Observer应用场景 提升集群的读性能。因为Observer和不参与提交和选举的投票过程所以可以通过往集群里面添加observer节点来提高整个集群的读性能。 跨数据中心部署。 比如需要部署一个北京和香港两地都可以使用的zookeeper集群服务并且要求北京和香港客户的读请求延迟都很低。解决方案就是把香港的节点都设置为observer。
2、集群架构 leader节点可以处理读写请求follower只可以处理读请求。follower在接到写请求时会把写请求转发给leader来处理。
Zookeeper数据一致性保证 全局可线性化(Linearizable )写入∶先到达leader的写请求会被先处理leader决定写请求的执行顺序。 客户端FIFO顺序∶来自给定客户端的请求按照发送顺序执行。
3、三节点Zookeeper集群搭建
环境准备三台虚拟机
192.168.65.156
192.168.65.190
192.168.65.200条件有限也可以在一台虚拟机上搭建zookeeper伪集群
1) 修改zoo.cfg配置添加server节点配置
# 修改数据存储目录
dataDir/data/zookeeper#三台虚拟机 zoo.cfg 文件末尾添加配置
server.1192.168.65.156:2888:3888
server.2192.168.65.190:2888:3888
server.3192.168.65.200:2888:3888server.AB:C:D
A 是一个数字表示这个是第几号服务器 集群模式下配置一个文件 myid这个文件在 dataDir 目录下这个文件里面有一个数据 就是 A 的值Zookeeper 启动时读取此文件拿到里面的数据与 zoo.cfg 里面的配置信息比较从而判断到底是哪个server。
B 是这个服务器的地址
C 是这个服务器Follower与集群中的Leader服务器交换信息的端口
D 是万一集群中的Leader服务器挂了需要一个端口来重新进行选举选出一个新的Leader而这个端口就是用来执行选举时服务器相互通信的端口。
2创建 myid 文件配置服务器编号
在dataDir对应目录下创建 myid 文件内容为对应ip的zookeeper服务器编号
cd /data/zookeeper
# 在文件中添加与 server 对应的编号注意上下不要有空行左右不要有空格
vim myid3启动zookeeper server集群
启动前需要关闭防火墙(生产环境需要打开对应端口)
# 分别启动三个节点的zookeeper server
bin/zkServer.sh start
# 查看集群状态
bin/zkServer.sh status4、Zookeeper四字命令
用户可以使用Zookeeper四字命令获取 zookeeper 服务的当前状态及相关信息
zookeeper 支持某些特定的四字命令与其交互用户获取 zookeeper 服务的当前状态及相关信息用户在客户端可以通过 telenet 或者 ncnetcat 向 zookeeper 提交相应的命令。
安装 nc 命令
# centos
yum install nc 四字命令格式
echo [command] | nc [ip] [port]ZooKeeper 常用四字命令主要如下
四字命令功能描述conf3.3.0版本引入的。打印出服务相关配置的详细信息。cons3.3.0版本引入的。列出所有连接到这台服务器的客户端全部连接/会话详细信息。包括接受/发送的包数量、会话id、操作延迟、最后的操作执行等等信息。crst3.3.0版本引入的。重置所有连接的连接和会话统计信息。dump列出那些比较重要的会话和临时节点。这个命令只能在leader节点上有用。envi打印出服务环境的详细信息。reqs列出未经处理的请求ruok测试服务是否处于正确状态。如果确实如此那么服务返回imok否则不做任何相应。stat输出关于性能和连接的客户端的列表。srst重置服务器的统计。srvr3.3.0版本引入的。列出连接服务器的详细信息wchs3.3.0版本引入的。列出服务器watch的详细信息。wchc3.3.0版本引入的。通过session列出服务器watch的详细信息它的输出是一个与watch相关的会话的列表。wchp3.3.0版本引入的。通过路径列出服务器watch的详细信息。它输出一个与session相关的路径。mntr3.4.0版本引入的。输出可用于检测集群健康状态的变量列表
https://zookeeper.apache.org/doc/current/zookeeperAdmin.html#sc_4lw
开启四字命令
方法1 在zoo.cfg 文件里加入配置项让这些指令放行
#开启四字命令
4lw.commands.whitelist*方法2在zk的启动脚本zkServer.sh中新增放行指令
#添加环境变量-Dzookeeper.4lw.commands.whitelist*
ZOOMAIN-Dzookeeper.4lw.commands.whitelist* ${ZOOMAIN}stat 命令
stat 命令用于查看 zk 的状态信息实例如下
$ echo stat | nc 192.168.65.156 21815、Zookeeper Leader 选举原理
zookeeper 的 leader 选举存在两个阶段一个是服务器启动时 leader 选举另一个是运行过程中 leader 服务器宕机。
在分析选举原理前先介绍几个重要的参数 服务器 ID(myid)编号越大在选举算法中权重越大 事务 ID(zxid)值越大说明数据越新权重越大 逻辑时钟(epoch-logicalclock)同一轮投票过程中的逻辑时钟值是相同的每投完一次值会增加
选举状态 LOOKING: 竞选状态 FOLLOWING: 随从状态同步 leader 状态参与投票 OBSERVING: 观察状态同步 leader 状态不参与投票 LEADING: 领导者状态
1、服务器启动时的 leader 选举
每个节点启动的时候都 LOOKING 观望状态接下来就开始进行选举主流程。这里选取三台机器组成的集群为例。第一台服务器 server1启动时无法进行 leader 选举当第二台服务器 server2 启动时两台机器可以相互通信进入 leader 选举过程。 每台 server 发出一个投票由于是初始情况server1 和 server2 都将自己作为 leader 服务器进行投票每次投票包含所推举的服务器myid、zxid、epoch使用myidzxid表示此时 server1 投票为1,0server2 投票为2,0然后将各自投票发送给集群中其他机器。 接收来自各个服务器的投票。集群中的每个服务器收到投票后首先判断该投票的有效性如检查是否是本轮投票epoch、是否来自 LOOKING 状态的服务器。 分别处理投票。针对每一次投票服务器都需要将其他服务器的投票和自己的投票进行对比对比规则如下 优先比较 epoch检查 zxidzxid 比较大的服务器优先作为 leader果 zxid 相同那么就比较 myidmyid 较大的服务器作为 leader 服务器 统计投票。每次投票后服务器统计投票信息判断是都有过半机器接收到相同的投票信息。server1、server2 都统计出集群中有两台机器接受了2,0的投票信息此时已经选出了 server2 为 leader 节点。 改变服务器状态。一旦确定了 leader每个服务器响应更新自己的状态如果是 follower那么就变更为 FOLLOWING如果是 Leader变更为 LEADING。此时 server3继续启动直接加入变更自己为 FOLLOWING。 2、运行过程中的 leader 选举
当集群中 leader 服务器出现宕机或者不可用情况时整个集群无法对外提供服务进入新一轮的 leader 选举。
变更状态。leader 挂后其他非 Oberver服务器将自身服务器状态变更为 LOOKING。每个 server 发出一个投票。在运行期间每个服务器上 zxid 可能不同。处理投票。规则同启动过程。统计投票。与启动过程相同。改变服务器状态。与启动过程相同。
6、Zookeeper 数据同步流程
在 Zookeeper 中主要依赖 ZAB 协议来实现分布式数据一致性。
ZAB 协议分为两部分 消息广播 崩溃恢复
1、消息广播
Zookeeper 使用单一的主进程 Leader 来接收和处理客户端所有事务请求并采用 ZAB 协议的原子广播协议将事务请求以 Proposal 提议广播到所有 Follower 节点当集群中有过半的Follower 服务器进行正确的 ACK 反馈那么Leader就会再次向所有的 Follower 服务器发送commit 消息将此次提案进行提交。这个过程可以简称为 2pc 事务提交整个流程可以参考下图注意 Observer 节点只负责同步 Leader 数据不参与 2PC 数据同步过程。 2、崩溃恢复
在正常情况消息下广播能运行良好但是一旦 Leader 服务器出现崩溃或者由于网络原理导致 Leader 服务器失去了与过半 Follower 的通信那么就会进入崩溃恢复模式需要选举出一个新的 Leader 服务器。在这个过程中可能会出现两种数据不一致性的隐患需要 ZAB 协议的特性进行避免。 Leader 服务器将消息 commit 发出后立即崩溃 Leader 服务器刚提出 proposal 后立即崩溃
ZAB 协议的恢复模式使用了以下策略 选举 zxid 最大的节点作为新的 leader 新 leader 将事务日志中尚未提交的消息进行处理
