Zookeeper选主流程和同步流程

Zookeeper的核心是原子广播（Zab：Zookeeper Atomic Broadcast），该机制保证各个Server之间的同步。Zab协议有两种模式，分别是恢复模式和广播模式。

恢复模式：当Leader挂掉或者启动Server时，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server的完成了和leader的状态同步以后，恢复模式就结束了。

广播模式：状态同步保证了Leader和所有Server都具有相同的系统状态。这时候当Server加入Zookeeper集群后，会先在恢复模式下启动该Server，发现Leader后，并和Leader进行状态同步，待到同步结束，它也参与消息广播，即进入广播状态。Zookeeper服务一直维持在Broadcast状态，直到Leader崩溃了或者Leader失去了大部分的Followers支持，才会进入恢复模式，从新选举Leader。Broadcast模式就如Paxos算法所述，Leader提起一个Proposal，由Followers进行投票，Leader对投票结果进行计算，如果通过一半以上，则该Proposal通过，否则什么也不做。广播模式需要保证Proposal被按顺序处理，因此Zookeeper采用了递增的事务ID号(zxid)来保证。所有的proposal都在被提出的时候加上了zxid。实现中zxid是一个64为的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch。低32位是个递增计数。

选主流程

在Zookeeper-3.4.0之后推荐使用的选举算法只有：FastLeaderElection，AuthFastLeaderElection和LeaderElection已经不推荐使用了。被标记成@Deprecated。所以选主流程我们只讲FastLeaderElection。

Paxos算法每个proposer都可以Proposal，所以不可避免的会产生冲突，这些冲突会给系统带来消耗和请求的延时，所以就产生了Leader的概念，所有的Proposal只能通过Leader提出，其他Follower不能提交Proposal。这样一来，如果Leader挂掉，就会导致集群不能提交Proposal，那么我们就要重新选出Leader，下面我们来看看Zookeeper的FastLeaderElection的实现思路：

Zookeeper集群中的Server启动时，是可以获取到其他Server开放的选举端口，IP地址，编号的，通过这些信息和选举算法必须选举出一个Leader。每个Server在运行选举算法时，会想所有的Server发送一个选自己为Leader的Proposal，同时也接收其他Server发过来的选Leader的Proposal。然后统计票数。这样集群就会产生N*N个网络连接。但是ZooKeeper从中也是做过一些优化工作的。首先，每一个Server在发送Proposal之前都会判断该Proposal是否是发送给自己的，如果是则直接存入统计选票的集合中，而不会通过网络连接发送给自己。其次，每一个peer节点只接受编号比自己大的peer的网络连接请求，这样产生的网络连接数就是(n-1)*(n-1)/2。选举Leader时，Leader广播消息到所有的Follower，该消息带zxid，告诉所有的Server，Leader目前的zxid到底是多大，看Follower或Observer需不需要同步，当收到大数据Follower的回复后，Leader才会成为真正的Leader。

当Leader挂掉或Leader已经和大多数Follower断开时，那么Zookeeper进入恢复模式，恢复模式需要重新选举出一个新的Leader，让所有的Server都恢复到一个正确的状态。

 

同步流程

当通过上述选主流程选出来的Leader，一定是所有Server中保存数据最多的节点，因为所有Znode的变更操作都要进过Leader，自然Leader肯定是集群中数据最完整，最新，最全的。在选举Leader的过程中，Leader会为所有的Follower或Observer创建LearnerHandler线程，用于接收它们的同步数据请求。

对比Leader发过来的zxid后，如果需要同步，Follower或Observer就将自己最大的zxid发送给Leader，因为Leader是提议是根据zxid来保证顺序性的，所以Leader拿到Server的最大zxid后，会将大于该zxid的所有数据同步到该Follower，完成同步后，通知Follower已经进入uptodate状态。Follower接收到uptodate消息后，就可以为Client提供服务了。