zookeeper 中master选举与leader选举
开始学zookeeper 中,master选举于leader 选举2个概念比较模糊,谈下自己的理解,如有不对地方请指出共同进步。1.master选举原理有多个master,每次只能有一个master负责主要的工作,其他的master作为备份,同时对负责工作的master进行监听,一旦负责工作的master挂掉了,其他的master就会收到监听的事件,从而去抢夺负责工作的权利,其他没有争夺到...
开始学zookeeper 中,master选举于leader 选举2个概念比较模糊,谈下自己的理解,如有不对地方请指出共同进步。
1.master选举原理
有多个master,每次只能有一个master负责主要的工作,其他的master作为备份,同时对负责工作的master进行监听,一旦负责工作的master挂掉了,其他的master就会收到监听的事件,从而去抢夺负责工作的权利,其他没有争夺到负责主要工作的master转而去监听负责工作的新master。
本质其实是利用zookeeper的临时节点的特性:临时节点随着会话的消亡二消亡,同一个临时节点只能创建一个,创建失败的节点(从master)对创建成功节点(主master)进行监控,一旦创建成功的节点(主master)会话消失,之前创建失败的节点(从master)就会监听到去抢夺创建临时节点。
举个例子:
第一步:zk有这样一个持久节点/distibuted_system
第二步:master1和master2同时启动,同时向向/distributed_system这个节点申请创建临时子节点ActiveOrStandByLock(同一时间只有一个请求能够创建成功)。
如果master1创建成功,这个节点(ActiveOrStandByLock)就不允许master2创建(锁的机制)
master1:active===》真正的master。路径:/distributed_system/ActiveOrStandByLock
master2:改为standby(master-back)。
同时对/distributed_system/ActiveOrStandByLock注册事件监听。
第三步:master1挂掉或者超过一定时间。节点会被删除(事件机制就会起作用),就会通知master2,master2就会在/distributed_system/ActiveOrStandByLock,同时修改状态为active。
备注:假如master1并没有挂掉,只有由于网络延时导致,当网络顺畅的时候就会出现“脑裂”状态。都认为自己是active。
解决脑裂的办法:对/distributed_system/ActiveOrStandByLock加一个权限ACL控制。master1对于这个节点/distributed_system/ActiveOrStandByLock没有权限。自己把状态改成standby。
2.leader 选举
leader 选择其实是paxos的一种经典实现,zk中使用我们的zab协议进行选举,具体请看一下过程图:
在我们zk选举leader中我们会想到如果我们的leader宕机怎么办?其实我们有一个重要指标那就是我们zk服务器中日志的记录的完整性,那么谁记录的日志完整性越好谁就选举作为leader,就是我们zk中的zxid,在选举过程中,首先比较我们的zxid,谁的zxid值越大就选谁,一个比较生动容易理解的图如下:
其实个人理解,leader选举我们理解就好,master选举应用场景会多一些,主要用到我们zk的特点节点管理,只要理解了,就很容易理解。
更多推荐
所有评论(0)