前言
在了解了zk的基本概念以后，我们来介绍一下ZK的核心原理。 没有了解过zk的同学，请先去了解zk的基本概念---->>>ZooKeeper入门指南
zk的角色
ZooKeeper的zab协议
zookeeper的核心是原子广播，这个机制保证了各个server之间的同步。实现这个机制的协议叫做Zab协议。 zab协议有两种模式，分别是恢复模式和广播模式。当服务启动或者leader崩溃后，Zab就进入了恢复模式。当leader被选举出来且超过一半的server完成了跟leader的状态同步以后，恢复模式结束。
zookeeper的工作原理
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
每个Server在工作过程中有三种状态：
- LOOKING：当前server没有发现leader的情况，通常出现在server启动时。
- LEADING：当前server成为了leader。
- FOLLOWING：leader已经选举出来，当前Server与之同步
一、选主流程
当leader奔溃或者leader失去超过一半的follower，这时候会进入恢复模式，恢复模式需要重新选举一个 新的leader，让所有server都恢复到一个正确的状态。
zk的选举算法有两种：一种是基于basic paxos算法实现的，另一种是基于 fast paxos算法实现的（系统默认）。
1.1 Basic Paxos 选举原理
paxos算法[帕克索斯]是最重要的分布式一致性算法，很多人都把它称作”分布式一致性协议“的代名词。分布式一致性算法是分布式计算领域的基础性问题，其最基本的功能是为了多个进程之间对某个某些值达成强一致性；进而解决分布式系统的高可用的问题 。
选举线程由当前server担任，该server负责对投票结果进行统计并选出推荐leader。
选举线程向集群中所有节点发起提议（proposal），包括自己。选举线程收到server的回复之后，通过ZXID验证对方的回复信息，是否是自己发起的提议。验证通过后，选举线程去获取对方server的ZXID并存储到当前提议列表。并获取对方server提议的leader信息，将推荐leader的关键信息存储到本次选举投票记录表。- 当
选举线程收到所有的server回复之后，判断本次选举投票记录表中是否有leader获得超过一半（(集群节点数/2)+1）票数的推荐。 若有，新leader产生，选举成功！ 若无，从选举投票记录表计算出ZXID最大的server节点，并将这个server节点设置成下一次要投票的server，继续选举流程。
- tips：为了选举成功，要求zookeeper集群部署必须是奇数节点。
1.2 Fast Paxos 选举原理
- 与
Basic Paxos选举的区别在于，选举线程在发起提议之初，会主动提议自己成为leader。 - 当其他server收到提议后，解决epoch和zxid的冲突，并接受对方的提议，然后向对方发送接受提议完成的消息，重复整个流程，完成选举。
二、状态同步流程
重新选举leader之后，zk就会进入状态同步的过程。
- leader等待server连接
- follower连接leader，将最大的zxid发送给leader
- leader根据follower的zxid确定同步点
- 完成同步后通知follower已经成为uptodate状态
- follower收到uptodate消息后，又可以重新接受client的请求了。
三、leader的工作流程
- 恢复数据
- 维持与learner的心跳，接受learner请求并判断learner的请求消息类型，根据不同 消息类型，进行不同处理。 消息类型包括：
- PING消息 - leader与learner心跳监测
- REQUEST消息 - follower发送的提议请求、写请求和同步请求
- ACK消息 - follower对提议的回复
- REVALIDATE消息 - 用来延长session的有效时间
四、follower的工作流程
- 向leader 发送请求（PING,REQUEST,ACK,REVALIDATE）
- 接收leader消息并处理
- 接收client请求，如果为写请求，转发送给leader
- 返回client结果
来源：oschina
链接：https://my.oschina.net/codingcloud/blog/4815797