zookeeper工作原理、过半机制、服务器为什么是奇数台

一、zookeeper工作原理

zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式，分别是恢复模式（选主）和广播模式（同步）。

在服务启动或者领导者崩溃之后，Zab就进入恢复模式，当领导者被选举出来，且大多数server都完成了和lender的状态同步之后，恢复模式就结束了。

状态同步保证了Server和leader具有同样的系统状态

一旦leader和多数follower进行了状态同步后，他就可以开始广播了，即进入广播状态。

这时，当一个server加入zookeeper中，他会在恢复模式下启动，发现leader并和leader进行状态同步。待到同步结束，他也开始消息广播。zookeeper服务一直维持在 Broadcast状态，直到leader崩溃了或者leader失去了大多数follower的支持。

广播模式需要保证proposal（提议）被按顺序处理，因此zookeeper采用了递增的事务id号（zxid）来保证。所有提议都在被提出时加上zxid。

现实中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变。每次一个leader被选出来，都有一个新的epoch，低32位是递增计数。
当leader崩溃或者失去大多数的follower，这时zookeeper进入恢复模式，恢复模式需要选举一个新的leader，让所有的server恢复到正确状态。

选举过程：
每个server启动以后都要询问其他server他要投票给谁

对于其他server的询问，server每次根据自己的状态都恢复自己推荐的leader的id和上一次处理事务的zxid（第一次的时候每个server都会推荐自己）

收到所有的server的回复后，计算出zxid最大的那个server，并将这个server的信息设置成下一次要投票的server。

计算这个过程中票数最多的server为获胜者，如果获胜者的票数超过半数，则该server被选为leader。否则，继续这个过程，直到leader被选举出来。

leader就会等待server进行连接

follower连接leader，将最大的zxid发送给leader

leader根据follower的zxid确定同步点

完成同步后通知follower已经成为uptodata状态

follower收到uptodata信息后，就可以重新接受client请求进行服务了

二、过半机制

zookeeper集群中所有的操作都必须遵从过半机制，即必须保证一半以上的Server同意这个proposal，这个提议才会成功。

zookeeper中的过半机制保证了zookeeper集群的数据一致性。

三、服务器为什么是奇数台

leader选举算法采用了paxos协议

paxos核心思想：当多数server写成功，则任务数据写成功。如果有3个server则2个写成功即可，当有4个或5个server，则3个写成功即可。

服务器数量一般为单数个：如果有3个server，最多允许有一个server挂掉，如果有4个server，则同样最多允许一个server挂掉，因此，我们可以看出，3台服务器和4台服务器的容灾能力是一样的，为了节省服务器资源，我们通常采用奇数数量，作为服务器部署数量。