Zookeeper（二）集群工作原理入门

这篇文章我们主要介绍Zookeeper集群间的工作原理。既然要组建集群，那必然要有两台或以上的服务器，这里假设我们有两台服务器用于部署Zookeeper，分别为server.1，server.2。

这里先记住，稍后使用。

1. 集群的启动

Zookeeper的三种角色

Leader，Follower，Observer。集群中的Leader角色仅有一个，会通过基于ZAB协议的快速选举（下篇文章中会介绍）选出。各个角色的作用稍后会讲。

Zookeeper运行过程中的状态

1. looking：当前节点正在询问谁是Leader。
2. leading：领导者状态，当前节点角色为Leader。
3. following：跟随者状态，表示Leader已经选举出来，当前节点角色是Follower。

1.1 server.1启动

server.1启动，状态变更为looking，尝试连接 server.2。由于server.2未启动，故连接失败，server.1等待server.2启动。

1.2 server.2启动

server.2启动，状态变更为looking，连接 server.1。
server.1与server.2连接创建完成后选举leader。

1.3 选举leader

server.1与server.2基于ZAB协议进行选举投票，获得半数以上投票（包括自己投自己）的server当选为leader。这里假设都投给了server.2，故server.2当选为leader。server.2状态变更为leading，server.1状态变更为following。

2. 客户端的读写

Zookeeper集群采用了一写多读的模式，写操作由leader完成。

2.1 客户端发送读命令

Leader，Follower都可直接处理读请求，从本地内存中读取数据并返回给客户端。

2.2 客户端发送写请求

Follower可接受写请求，但不能直接处理，而需要将写请求转发给Leader处理。除了多了一步请求转发，其余过程与直接请求Leader相同。

1. Client向server.1发出一个写请求。
2. server.1把请求转发送给Leader。
3. Leader收到写请求，自己先保存请求数据，然后通知其他Follower可以暂存数据了。
4. 成功暂存数据的Follwer通知Leader，告知自己已经暂存数据了。
5. Leader如若收到半数以上节点的告知，就向其他节点发送数据落盘的请求。
6. server.1把最终的处理结果返回给Client。

ps：步骤中的3、4、5中的同步数据细节将在下篇文章中介绍，这里明白流程就好。

3. 角色的作用

通过上述功能的介绍，总结下不同角色的作用：

1. Leader：处理读请求；处理写请求；负责集群间节点的数据同步。
2. Follower：处理读请求；负责投票。
3. 补充一种角色 Observer：处理读请求；不参与投票。 Observer的引入，可以解决随着集群规模扩大，参与投票的半数以上节点越来越多的问题，从而提高整个集群处理读、写请求的效率。

4. 可用性问题

上述举例中，我们只用了两台服务器部署。如果作为Leader的server.2故障，会导致什么问题？由于Zookeeper的ZAB协议规定，选举时需要半数以上的节点达成一致，因此server.1无法选举自己成为Leader，这就导致了Zookeeper集群不可用。所以当我们正式部署Zookeeper时，建议使用三台或以上的服务器。