以下基于小白理解,如果有错误,请指正:
1、约定
Leader:领导者 Follower:跟随者 oberserver:观察者
CAP理论:
2、原理
zk基础数据结构是DataTree(先不研究底层数据结构),核心思想就是基于Zab协议(Leader选举)+ 二段式分布式事务。
1、Leader选举 : 客户端发送了一个请求,zk集群里所有节点启动,进入Leader选举(a、比较各个节点里的事务id(zxid),最大的就是Leader;如果各个节点里的zxid一致的情况,则比较serverid(myid),最大的就是Leader)。
2 、ACK :当从Follower里选举出Leader后,Leader将会将请求转化为全局唯一的事务请求(二段式事务开启),然后将请求广播给所有Follwer,等待响应(ACK)。
3、Commit : 只有当Leader得到超过半数Follower的响应情况下,才会提交事务,同时将通知所有的Follower提交事务。
3、开发中遇到的问题
当往已经选举出Leader的zk集群里动态添加一个节点,此时整个集群是不会重新进入Leader选举的,得重启进入恢复模式。
Leader选举选举发生在(Zab协议中恢复模式):
1、集群启动
2、Leader挂掉
3、Follower挂掉后,Leader发现已经没有过半的Follower投票给自己,此时整个zk集群宕机,不能对外提供服务。
4、zk脑裂(split-brain)
当因为整个zk集群在选举过程中通信出现问题,而分裂为多个zk集群,此时各个zk集群会各自选举出自己的Leader,一旦通信恢复,这个集群将会出现多个Leader。
解决方法:Leader的过半选举已经解决了这个问题,只有超过过半机器存活的情况下,才会进行选举。
当整个zk集群脑裂成两个zk集群,因为两个集群里的节点都不会超过原先过半机器存活,所以这两个zk集群实际是不会进行选举的。
实际上啥都不用做,别用太老的zk版本就好了。
大佬分析博客,在下佩服: