Zookeeper(三)ZAB协议的两种基本模式:崩溃恢复和广播消息
来源:互联网 发布:抢票软件原理 编辑:程序博客网 时间:2024/06/10 16:03
ZAB协议的两种基本模式:崩溃恢复和广播消息
ZooKeeper会有两种情况下进行Leader选举
1)集群初始化
2)集群的Leader失去连接,需要重新选举一个新的Leader。
服务器进行选举时投票主要包含两个信息:推举服务器的唯一标识和事务编号:服务器的ID和ZXID。
服务器进行投票时发送消息自己的投票(ID,ZXID)到集群中的其他服务器,服务器在收到其他服务器发来的投票时,会和自己的投票进行比较,
首先,比较事务ID,
如果其他服务器的ZXID大于自己的ZXID,则更新自己的投票,自己的投票更新为其他服务器的投票(即收到的服务器发来的投票),并将的投票投出来集群中另外的服务器;
如果其他服务器的ZXID小于自己的ZXID,不用更新自己投票,保留自己原来的投票;
如果其他服务器的ZXID与自己的ZXID相等,则比较服务器ID的大小,如果ID比自己的ID小,则保留自己的投票;如果ID比自己的ID大,则更新自己的投票为其他服务器的投票(即收到的服务器发来的投票);
当服务器收到的投票推举某个服务器为Leader的票数小于集群的节点一半数时,则该服务器就被选举为Leader,
该服务器会修改自己的状态为LEADING,其他服务器也会修改自己的状态为FOLLOWING。
投票对象:
org.apache.zookeeper.server.quorum.Vote{
final private long id; //服务器的id,群集模式每个服务器都有个配置文件myid
final private long zxid; //服务器的事务id
final private long electionEpoch; //表明投票是哪个轮次的,每次发起Leader选举的投票轮次都会在原来的轮次上加1,以此来区别投票是在同一投票轮次的。
final private long peerEpoch; //被推举的Leader的epoch
inal private ServerState state; //服务器的状态,默认是寻找Leader的状态:ServerState.LOOKING,服务器的状态查看下面的ServerState类
}
服务器状态:
public enum ServerState {
LOOKING, FOLLOWING, LEADING, OBSERVING;
}
客户端每发送一个更新请求,ZooKeeper都会生成一个全局唯一的递增编号,这个编号反映了所有事务操作的先后顺序,
这个唯一编号就是事务ID(ZXID),只有更新请求才算是事务请求。
为保证按照事务的ZXID先后顺序来处理,Leader服务器会分别为每个Follower服务器创建一个队列,并将事务的先后顺序放入队列中,
并按照FIFO的策略进行消息发送。收到需要处理的事务后,Follower服务器会首先以及事务日志的形式写入服务器的磁盘中,写入成功后
会向Leader服务器发送ACK响应。当Leader服务器收到超过一半的Follower服务器的ACK响应后,会向所有Follower服务器广播Commit消息,
收到Commit消息的Follower服务器也会完成对事务的提交。
如果接收到事务请求的是Follower服务器,它会将请求转发给Leader服务器处理。
1.崩溃恢复
Leader服务器选举ZooKeeper会有两种情况下进行Leader选举
1)集群初始化
2)集群的Leader失去连接,需要重新选举一个新的Leader。
服务器进行选举时投票主要包含两个信息:推举服务器的唯一标识和事务编号:服务器的ID和ZXID。
服务器进行投票时发送消息自己的投票(ID,ZXID)到集群中的其他服务器,服务器在收到其他服务器发来的投票时,会和自己的投票进行比较,
首先,比较事务ID,
如果其他服务器的ZXID大于自己的ZXID,则更新自己的投票,自己的投票更新为其他服务器的投票(即收到的服务器发来的投票),并将的投票投出来集群中另外的服务器;
如果其他服务器的ZXID小于自己的ZXID,不用更新自己投票,保留自己原来的投票;
如果其他服务器的ZXID与自己的ZXID相等,则比较服务器ID的大小,如果ID比自己的ID小,则保留自己的投票;如果ID比自己的ID大,则更新自己的投票为其他服务器的投票(即收到的服务器发来的投票);
当服务器收到的投票推举某个服务器为Leader的票数小于集群的节点一半数时,则该服务器就被选举为Leader,
该服务器会修改自己的状态为LEADING,其他服务器也会修改自己的状态为FOLLOWING。
投票对象:
org.apache.zookeeper.server.quorum.Vote{
final private long id; //服务器的id,群集模式每个服务器都有个配置文件myid
final private long zxid; //服务器的事务id
final private long electionEpoch; //表明投票是哪个轮次的,每次发起Leader选举的投票轮次都会在原来的轮次上加1,以此来区别投票是在同一投票轮次的。
final private long peerEpoch; //被推举的Leader的epoch
inal private ServerState state; //服务器的状态,默认是寻找Leader的状态:ServerState.LOOKING,服务器的状态查看下面的ServerState类
}
服务器状态:
public enum ServerState {
LOOKING, FOLLOWING, LEADING, OBSERVING;
}
2.广播消息
数据更新(事务请求)客户端每发送一个更新请求,ZooKeeper都会生成一个全局唯一的递增编号,这个编号反映了所有事务操作的先后顺序,
这个唯一编号就是事务ID(ZXID),只有更新请求才算是事务请求。
为保证按照事务的ZXID先后顺序来处理,Leader服务器会分别为每个Follower服务器创建一个队列,并将事务的先后顺序放入队列中,
并按照FIFO的策略进行消息发送。收到需要处理的事务后,Follower服务器会首先以及事务日志的形式写入服务器的磁盘中,写入成功后
会向Leader服务器发送ACK响应。当Leader服务器收到超过一半的Follower服务器的ACK响应后,会向所有Follower服务器广播Commit消息,
收到Commit消息的Follower服务器也会完成对事务的提交。
如果接收到事务请求的是Follower服务器,它会将请求转发给Leader服务器处理。
0 0
- Zookeeper(三)ZAB协议的两种基本模式:崩溃恢复和广播消息
- ZooKeeper的原子广播(ZAB协议)
- zookeeper ZAB 原子消息广播
- zookeeper ZAB 原子消息广播
- Zookeeper之Zab协议介绍(三)
- ZOOKEEPER的ZAB协议
- ZooKeeper的ZAB协议。
- zab协议(zookeeper atomic broadcast)原子广播
- Zookeeper的一致性协议:Zab
- Zookeeper的一致性协议:Zab
- zookeeper的一致性协议:Zab
- ZooKeeper的一致性协议:Zab
- Zookeeper的一致性协议:Zab
- Zookeeper的一致性协议:Zab
- Zookeeper的一致性协议:Zab
- Hadoop学习笔记(三)——zookeeper的一致性协议:ZAB
- Zookeeper原子广播Zab
- ZooKeeper-理解Paxos算法和ZAB协议(转载)
- |poj 3311|状压DP|Hie with the Pie
- 关于微服务的两篇文章以及Eventuate
- lost in the city(枚举)
- Javascript闭包(Closure)简化精简版
- 字符编码 ASCII,Unicode 和 UTF-8 概念扫盲
- Zookeeper(三)ZAB协议的两种基本模式:崩溃恢复和广播消息
- C 练习实例28
- Cocos场景遍历与渲染
- CSS预处理器--Sass
- mapreduce标准过程
- IntelliJ IDEA 永久破解的方法
- Node.js 基于socket.io聊天室的BUG解决经过
- 自定义CSDN博客中图片上的水印内容
- vb.net总结