Zookeeper 节点宕掉之后的工作
2013-11-06 16:51
211 查看
假设咱们有5台机器:A-1 B-2 C-3 D-4 E-5 (后面的数字为myid)。
为简化过程咱们使用第一次启动ZK,假设是按我之前写的顺序启动,那么应该是C为leader,其它节点为follower(为什么会这样?请大家自行充电ZK选举算法)。
在集群的运行情况下,会有读写的操作,而咱们需要关注的是写操作。ZK集群为保证数据的一致性所有的操作都是由leader完成,之后再由leader同步给follower。重点就在这儿,ZK并不会确保所有节点都同步完数据,只要有大多数节点(即n/2+1)同步成功即可。
咱们假设有一个写操作成功那么现在数据只存在于节点C,之后C再同步给A与B。
但是如果有一台恢复那么至少会有一个节点存有最新的数据,那么在选举中这个节点将会被选为leader,然后将数据同步到其它节点--即恢复服务。
为简化过程咱们使用第一次启动ZK,假设是按我之前写的顺序启动,那么应该是C为leader,其它节点为follower(为什么会这样?请大家自行充电ZK选举算法)。
在集群的运行情况下,会有读写的操作,而咱们需要关注的是写操作。ZK集群为保证数据的一致性所有的操作都是由leader完成,之后再由leader同步给follower。重点就在这儿,ZK并不会确保所有节点都同步完数据,只要有大多数节点(即n/2+1)同步成功即可。
咱们假设有一个写操作成功那么现在数据只存在于节点C,之后C再同步给A与B。
结果:
这时候宕掉任意三个节点,根据选举策备可知这两个节点并不能选出leader(因为无论怎么选都不会有超过半数的节点支持其中一个节点),所以两个节点都转到looking状态--即无法正常服务。但是如果有一台恢复那么至少会有一个节点存有最新的数据,那么在选举中这个节点将会被选为leader,然后将数据同步到其它节点--即恢复服务。
相关文章推荐
- Zookeeper核心工作机制(zookeeper特性、zookeeper数据结构、节点类型)
- Zookeeper核心工作机制(zookeeper特性、zookeeper数据结构、节点类型)
- 当hover结束之后获取鼠标上的节点
- 《关于痴者》---大学之后的学习工作
- zookeeper怎么保证节点唯一性
- Juery新增节点之后事件绑定无效
- 工作半个月之后
- 送给各位正在努力的 码农们 工作之后有时间常回家看看
- 在单链表中将两个链表合并,合并之后的链表使用的是输入链表的节点空间,合并之后输入链表变为空表
- 02 第一份实习工作之后的三个月
- zookeeper实时感知到主节点服务器的上下线
- Zookeeper节点数量为什么建议是奇数个
- ZooKeeper故障节点替换过程详解
- zookeeper的leader选举和最大故障节点数
- 签了工作之后才发现,自己太草率了.....我看过的关于职业规划最好最全面的一篇文章
- 工作之后该如何学习?
- JSONKit 在iPad air还有iphone5S之后的设备上不工作
- Zookeeper实例ZkClient API-获取节点数据内容
- zookeeper 节点启动时的更新机制
- 大白话解读KBEngine服务器引擎——第三期——编译之后的工作