对分布式协调服务系统zookeeper的学习做一个简单的总结,本文主要简介zookeeper的选举机制。

（一） zookeeper的介绍

zookeeper实际上是yahoo开发的，用于分布式中一致性处理的框架。最初其作为研发Hadoop时的副产品。但由于分布式协调服务系统的处理困难，其他分布式服务框架没必要重新开放一款框架来处理。因此在很多分布式服务的框架产品中我们都能看的zookeeper的影子，笔者目前接触和了解的就有阿里开发的开源SOA框架Dubbo以zookeeper作为其注册中心，HadoopHA借助zookeeper进行主备NN的失效转移。还有众多的大数据框架都借助了zookeeper，如kafka（分布式消息队列），hbase（分布式NoSQL数据库）等！由此可见zookeeper在分布式服务的框架中的重要地位。

（二） zookeeper的主要作用

1.服务发现

2.分布式锁

3.配置管理

4.分布式领导选举

这一切的作用源于zookeeper提供了一个类似于Linux的树状结构,我们可以将其作为一个小型的文件系统,但只适合存储少量信息,其一个节点默认限制的容量最大为1M(现实中远比这个小,完全不适合存储大量文件).zookeeper还对每个节点提供了监听/通知机制.因此我们完全可以将其作为一个文件系统+通知机制去理解.

（三） zookeeper的架构

zookeeper中的角色

zookeeper是一个典型的基于主从复制的高可用集群，在zookeeper的集群中，每个节点都会成为以下角色中的一种：

leader：一个Zookeeper集群同一时间只会有一个实际工作的Leader，它会发起并维护与各Follwer及Observer间的心跳。所有的写操作必须要通过Leader完成再由Leader将写操作广播（主从复制）给其它服务器。

follower：一个Zookeeper集群可能同时存在多个Follower，它会响应Leader的心跳。Follower可直接处理并返回客户端的读请求，同时会将写请求转发给Leader处理，并且负责在Leader处理写请求时对请求进行投票（即leader写入数据复制给follower，一个follower完成之后会返回leader一个ACK，即为投票。当这个写操作票数超过集群的一半时，返回写入操作成功）。

Observer：类似于follower，但不能参与投票。也可以对外提供读服务，转发写服务到leader，也会同步leader的数据（保证数据读取的一致性）。

zookeeper的一致性协议 ZAB（原子广播）

基于该协议，zookeeper实现了一种主从模式的系统架构来保持集群中各个副本之间的数据一致性。

根据ZAB协议，所有的写操作都必须通过Leader完成，Leader写入本地日志后再复制到所有的Follower节点。

一旦Leader节点无法工作，ZAB协议能够自动从Follower节点中重新选出一个合适的替代者，即新的Leader，该过程即为领导选举。该领导选举过程，是ZAB协议中最为重要和复杂的过程。

zk中的写流程（如果写操作是先访问的follower服务器，先转发至leader再进行写操作）：

由上图可见，通过Leader进行写操作，主要分为五步：

1. 客户端向Leader发起写请求
2. Leader将写请求以Proposal的形式发给所有Follower并等待ACK
3. Follower收到Leader的Proposal后返回ACK
4. Leader得到过半数的ACK（Leader对自己默认有一个ACK）后向所有的Follower和Observer发送Commmit
5. Leader将处理结果返回给客户端

这里要注意

• Leader并不需要得到Observer的ACK，即Observer无投票权
• Leader不需要得到所有Follower的ACK，只要收到过半的ACK即可，同时Leader本身对自己有一个ACK。上图中有4个Follower，只需其中两个返回ACK即可，因为(2+1) / (4+1) > 1/2
• Observer虽然无投票权，但仍须同步Leader的数据从而在处理读请求时可以返回尽可能新的数据

zk的读操作：任何zk的集群服务器都可以完成读操作（数据的最终一致性），根据ZAB 协议，写操作并不保证更新被所有的 Follower 立即确认，因此通过部分 Follower 读取数据并不能保证读到最新的数据，而部分 Follwer 及 Leader 可读到最新数据。如果一定要保证单一系统镜像，可在读操作前使用 sync 方法。

zookeeper的选举机制-FastLeaderElection算法

FastLeaderElection选举算法是标准的Fast Paxos算法实现，可解决LeaderElection选举算法收敛速度慢的问题。

服务器状态

• LOOKING：不确定Leader状态。该状态下的服务器认为当前集群中没有Leader，会发起Leader选举
• FOLLOWING： 跟随者状态。表明当前服务器角色是Follower，并且它知道Leader是谁
• LEADING ：领导者状态。表明当前服务器角色是Leader，它会维护与Follower间的心跳
• OBSERVING： 观察者状态。表明当前服务器角色是Observer，与Folower唯一的不同在于不参与选举，也不参与集群写操作时的投票

再了解原理之前，我们需要知道参与选择的以下几个参数：

• 服务器 ID：比如有三台服务器，编号分别是 1,2,3。编号越大在选择算法中的权重越大。即集群配置中的myid!
• 数据 ID：    服务器中存放的最新数据 version。值越大说明数据越新，在选举算法中数据越新权重越大。
• 逻辑时钟： 也叫投票的次数，同一轮投票过程中的逻辑时钟值是相同的。每投完一次票这个数据就会增加，然后与接 4000 收到的其它服务器返回的投票信息中的数值相比，根据不同的值做出不同的判断。

全新集群选举:全新集群的数据ID以及逻辑时钟都是相同的!所以只能比较服务器ID(myid)!同时当参与集群过半时,选举结束.

假设目前有 5 台服务器，每台服务器均没有数据，它们的编号分别是1,2,3,4,5,按编号依次启动，它们的选择举过程如下：

1.服务器 1 启动，给自己投票，然后发投票信息，由于其它机器还没有启动所以它收不到反馈信息， 1 的状态一直属于 LOOKING。

2.服务器 2 启动，给自己投票，并与 1 交换结果，由于 2 的编号大，所以 2 胜出，但此时投票数没有大于半数，所以两个服务器的状态依然是 LOOKING。

3.服务器 3 启动，给自己投票，并与 1,2 交换信息，由于 3 的编号最大，所以 3 胜出，此时投票数正好大于半数，所以 3 成为领导者， 1,2 成为小弟。

4.服务器 4 启动，给自己投票，并与 1,2,3 交换信息，尽管 4 的编号大，但之前 3 已经胜出，所以 4 只能成为小弟。

5.服务器 5 启动，后面的逻辑同 4 ，成为小弟.

非全新集群选举:对于运行正常的 zookeeper 集群，中途有机器 down 掉，需要重新选举时，选举过程就需要加入数据 ID、服务器 ID 和逻辑时钟。这样选举的标准就变成：

1. 逻辑时钟小的选举结果被忽略，重新投票；(选票过期)
2. 统一逻辑时钟后，数据 id 大(version)的胜出；
3. 数据 id 相同的情况下，服务器 id 大的胜出；

根据这个规则选出 leader。

（四）zookeeper的数据一致性保证

1.顺序一致性：从同一个客户端发出的更新操作会按发送的顺序被顺序执行。

2.原子性：更新操作要么成功要么失败，无中间状态。.

3.单一系统镜像：一个客户端只会看到同一份view，无论连接哪个服务器(因为zk的半数机制,还是有一定时间的延迟)！

4.可靠性：一旦一个更新被应用，该更新将会被持久化，直到客户端更新该结果；如果一个客户端得到更新成功的状态码（前面提到半数集群更新成功之后leader向集群的节点和客户端发送commit状态表明更新成功！），则该更新一定生效！；任何一个客户端能看到更新之后的结果，将不会被回滚更新操作，即便是从失败中恢复。

5.实时性：保证客户端在一定时间内（一般几十秒）看到最新的view。

（五）zookeeper的注意事项

1.zookeeper的单一镜像并不保证多个客户端在同一时刻的单一镜像（可能有的zk集群服务器数据不是最新的），如果要实现这种效果，请在读取数据之前调用sync操作！

2.zookeeper的读比写性能好，原因是zk集群的所有服务器都能完成读请求，而写只能通过leader。

3.zookeeper的集群数量设置为奇数，且最小有3台集群服务器，才能保证zk的选举机制正常进行（ZAB协议）！

4.zookeeper若需要容忍f个服务器的宕机，那么集群需要配置2f+1个以上的服务器！

总结

• 由于使用主从复制模式，所有的写操作都要由Leader主导完成，而读操作可通过任意节点完成，因此Zookeeper读性能远好于写性能，更适合读多写少的场景
• 虽然使用主从复制模式，同一时间只有一个Leader，但是Failover机制保证了集群不存在单点失败（SPOF）的问题
• ZAB协议保证了Failover过程中的数据一致性
• 服务器收到数据后先写本地文件再进行处理，保证了数据的持久性