Zookeeper内部原理

Leader选举

选举机制
- 半数机制：集群中半数以上机器存活，集群可⽤。所以Zookeeper适合安装奇数台服务器。
- Zookeeper虽然在配置⽂件中并没有指定Master和Slave。但是，Zookeeper⼯作时，是有⼀个节点为Leader，其它为Follower，Leader是通过内部的选举机制产⽣的。
集群⾸次启动

假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这⼀点上，都是⼀样的。假设这些服务器依序启动，来看看会发⽣什么
1. 服务器1启动，此时只有它⼀台服务器启动了，它发出去的报⽂没有任何响应，所以它的选举状态⼀直是LOOKING状态。
2. 服务器2启动，它与最开始启动的服务器1进⾏通信，互相交换⾃⼰的选举结果，由于两者都没有历史数据，所以id值较⼤的服务器2胜出，但是由于没有达到超过半数以上的服务器都同意选举它(这个例⼦中的半数以上是3)，所以服务器1、2还是继续保持LOOKING状态。
3. 服务器3启动，根据前⾯的理论分析，服务器3成为服务器1、2、3中的⽼⼤，⽽与上⾯不同的是，此时有三台服务器选举了它，所以它成为了这次选举的Leader。
4. 服务器4启动，根据前⾯的分析，理论上服务器4应该是服务器1、2、3、4中最⼤的，但是由于前⾯已经有半数以上的服务器选举了服务器3，所以它只能接收当⼩弟的命了。
5. 服务器5启动，同4⼀样称为follower。
集群⾮⾸次启动

每个节点在选举时都会参考⾃身节点的zxid值（事务ID）；优先选择zxid值⼤的节点称为Leader!!

ZAB⼀致性协议

分布式数据⼀致性问题

为什么会出现分布式数据⼀致性问题?

将数据复制到分布式部署的多台机器中，可以消除单点故障，防⽌系统由于某台（些）机器宕机导致的不可⽤。
通过负载均衡技术，能够让分布在不同地⽅的数据副本全都对外提供服务。有效提⾼系统性能。

在分布式系统中引⼊数据复制机制后，多台数据节点之间由于⽹络等原因很容易产⽣数据不⼀致的情况。

举例:当客户端Client1将系统中的⼀个值K1由V1更新为V2，但是客户端Client2读取的是⼀个还没有同步更新的副本，K1的值依然是V1,这就导致了数据的不⼀致性。其中，常⻅的就是主从数据库之间的复制延时问题。

ZAB协议

ZK就是分布式⼀致性问题的⼯业解决⽅案，paxos是其底层理论算法(晦涩难懂著名)，其中zab，raft和众多开源算法是对paxos的⼯业级实现。ZK没有完全采⽤paxos算法，⽽是使⽤了⼀种称为Zookeeper Atomic Broadcast（ZAB，Zookeeper原⼦消息⼴播协议）的协议作为其数据⼀致性的核⼼算法。

ZAB 协议是为分布式协调服务 Zookeeper 专⻔设计的⼀种⽀持崩溃恢复和原⼦⼴播协议。主备模式保证⼀致性

ZK怎么处理集群中的数据？

所有客户端写⼊数据都是写⼊Leader中，然后，由 Leader 复制到Follower中。ZAB会将服务器数据的状态变更以事务Proposal的形式⼴播到所有的副本进程上，ZAB协议能够保证了事务操作的⼀个全局的变更序号(ZXID)。

⼴播消息

ZAB 协议的消息⼴播过程类似于⼆阶段提交过程。对于客户端发送的写请求，全部由 Leader 接收，Leader 将请求封装成⼀个事务 Proposal(提议)，将其发送给所有 Follwer ，如果收到超过半数反馈ACK，则执⾏ Commit 操作（先提交⾃⼰，再发送 Commit 给所有 Follwer）。

发送Proposal到Follower

Leader接收Follower的ACK

超过半数ACK则Commit

不能正常反馈Follower恢复正常后会进⼊数据同步阶段最终与Leader保持⼀致！

细节
- Leader接收到Client请求之后，会将这个请求封装成⼀个事务，并给这个事务分配⼀个全局递增的唯⼀ID，称为事务ID（ZXID），ZAB 协议要求保证事务的顺序，因此必须将每⼀个事务按照 ZXID 进⾏先后排序然后处理。
- ZK集群为了保证任何事务操作能够有序的顺序执⾏，只能是 Leader 服务器接受写请求，即使是 Follower 服务器接受到客户端的请求，也会转发到 Leader 服务器进⾏处理。