5 zookeeper内部原理

第五部分 zookeeper内部原理

5.1 Leader选举

选举机制

• 半数机制:集群中半数以上机器存活，集群可用。所以Zookeeper适合安装奇数台服务器。
• Zookeeper虽然在配置文件中并没有指定Master和Slave。但是，Zookeeper⼯作时，是有一个节点为Leader，其它为Follower，Leader是通过内部的选举机制产生的。

集群⾸次启动

假设有五台服务器组成的Zookeeper集群，它们的id从1-5，同时它们都是最新启动的，也就是没有历史数据，在存放数据量这一点上，都是一样的。假设这些服务器依序启动，来看看会发生什么

Zookeeper的选举机制

(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!!

5.2 ZAB一致性协议

1. 分布式数据一致性问题

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

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

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

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

2. ZAB协议

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

ZAB协议

ZAB 协议是为分布式协调服务 Zookeeper 专⻔设计的一种支持崩溃恢复和原子广播协议。

主备模式保证一致性

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

⼴播消息

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

1. 发送Proposal到Follower

2. Leader接收Follower的ACK

3. 超过半数ACK则Commit

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

细节

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

zk提供的应该是最终一致性的标准。zk所有节点接收写请求之后可以在一定时间内保证所有节点都能看到该条数据!!

Leader 崩溃问题

Leader宕机后，ZK集群⽆法正常工作，ZAB协议提供了一个⾼效且可靠的leader选举算法。

Leader宕机后，被选举的新Leader需要解决的问题

• ZAB 协议确保那些已经在 Leader 提交的事务最终会被所有服务器提交。
• ZAB 协议确保丢弃那些只在 Leader 提出/复制，但没有提交的事务。

基于上面的目的，ZAB协议设计了一个选举算法：能够确保已经被Leader提交的事务被集群接受，丢弃还没有提交的事务。

这个选举算法的关键点：保证选举出的新Leader拥有集群中所有节点最大编号(ZXID)的事务！！