Zookeeper面试常见的11个连环炮(3)

Zookeeper的核心是原子广播，这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。
Zab协议有两种模式，它们 分别是恢复模式（选主）和广播模式（同步）。
Zab协议 的全称是 Zookeeper Atomic Broadcast** （Zookeeper原子广播）。Zookeeper 是通过 Zab 协议来保证分布式事务的最终一致性。Zab协议要求每个 Leader 都要经历三个阶段：发现，同步，广播。
当服务启动或者在领导者崩溃后，Zab就进入了恢复模式，当领导者被选举出来，且大多数Server完成了和 leader的状态同步以后，恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。
为了保证事务的顺序一致性，zookeeper采用了递增的事务id号（zxid）来标识事务。所有的提议（proposal）都在被提出的时候加 上了zxid。实现中zxid是一个64位的数字，它高32位是epoch用来标识leader关系是否改变，每次一个leader被选出来，它都会有一 个新的epoch，标识当前属于那个leader的统治时期。低32位用于递增计数。
epoch：可以理解为皇帝的年号，当新的皇帝leader产生后，将有一个新的epoch年号。
每个Server在工作过程中有三种状态：
LOOKING：当前Server不知道leader是谁，正在搜寻。LEADING：当前Server即为选举出来的leader。FOLLOWING：leader已经选举出来，当前Server与之同步。NO4：Zookeeper为什么要这么设计？
ZooKeeper设计的目的是提供高性能、高可用、顺序一致性的分布式协调服务、保证数据最终一致性。
高性能（简单的数据模型）
采用树形结构组织数据节点；全量数据节点，都存储在内存中；Follower 和 Observer 直接处理非事务请求；高可用（构建集群）
半数以上机器存活，服务就能正常运行自动进行 Leader 选举顺序一致性（事务操作的顺序）
每个事务请求，都会转发给 Leader 处理每个事务，会分配全局唯一的递增id（zxid，64位：epoch 自增 id）最终一致性
通过提议投票方式，保证事务提交的可靠性提议投票方式，只能保证 Client 收到事务提交成功后，半数以上节点能够看到最新数据NO5：你知道Zookeeper中有哪些角色？