111111 zookeeper功能及工做原理

Zookeeper server工做原理

Zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫作Zab协议。Zab协议有两种模式，它们分别是恢复模式和广播模式。当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数server的完成了和leader的状态同步之后，恢复模式就结束了。状态同步保证了leader和server具备相同的系统状态。

 

ZAB 协议的核心：定义了事务请求的处理方式。

　　全部事务请求必须由一个全局惟一的服务器来协调处理，这样的服务器被称为 Leader服务器，而余下的其余服务器则成为 Follower 服务器。 Leader 服务器负责将一个客户端事务请求转换成一个事务proposal（提议），并将该 Proposal分发给集群中全部的Follower服务器。以后 Leader 服务器须要等待全部Follower 服务器的反馈,一旦超过半数的Follower服务器进行了正确的反馈后，那么 Leader 就会再次向全部的 Follower服务器分发Commit消息，要求其将前一个proposal进行提交。

　　这种事务处理方式与2PC（两阶段提交协议）区别在于，两阶段提交协议的第二阶段中，须要等到全部参与者的"YES"回复才会提交事务，只要有一个参与者反馈为"NO"或者超时无反馈，都须要中断和回滚事务。

 

zxid是处理事务的id，是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。

因此每一个zk节点都会记录上次运行事物到zxid，它能够用来记录当前zk节点运行到哪一个事物了。

同时zxid也是leader选举的时候用来选择server的依据，每一个node广播本身的id和zxid，你们会选zxid最大的那个作为leader，由于zxid越大说明执行的事物越多，node最解决最后的结果。选举成功后follower链接leader，上报本身的zxid，leader会根据zxid，从事务日志中将本身的内容与follower的同步一致。

在恢复模式下，若是是刚从崩溃状态恢复的或者刚启动的server还会从磁盘快照中恢复数据和会话信息，zk会记录事务日志并按期进行快照，方便在恢复时进行状态恢复。

 

https://www.cnblogs.com/jian-xiao/p/5821675.html

http://blog.csdn.net/xqb_756148978/article/details/52259381

 

https://www.cnblogs.com/wangn/p/3361821.html