Zookeeper的集群

一、集群角色

Leader 角色
Leader 服务器是整个 zookeeper 集群的核心，主要的工作任务有两项：
1》事物请求的唯一调度和处理者，保证集群事物处理的顺序性(通过zxid来控制)。
2》集群内部各服务器的调度者。

Follower 角色
Follower 角色的主要职责是：
1》处理客户端非事物请求(对应读操作)、转发事物请求(对应写操作)给 leader 服务器。
2》参与事物请求 Proposal 的投票（Leader 发起的提案，要求 Follower 投票，需要半数以上follower节点通过，leader才会commit数据。）
3》参与 Leader 选举的投票。

Observer 角色
Observer 的工作原理与 follower 角色基本一致，而它和 follower 角色唯一的不同在于 observer 不参与任何形式的投票，包括事务请求Proposal的投票和leader选举的投票。简单来说observer服务器只提供非事物请求服务，通常在于不影响集群事务处理能力的前提下提升集群非事物处理的能力。

集群组成
通常 zookeeper 是由2n+1台server组成，每个server都知道彼此的存在。对于2n+1台server，只要有n+1台（大多数）server可用，整个系统保持可用。
我们已经了解到，一个 zookeeper 集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通信。
基于这个特性，如果要搭建一个能够允许F台机器down掉的集群，那么就要部署2*F+1台服务器构成的 zookeeper 集群。因此3台机器构成的 zookeeper 集群，能够在挂掉1台机器后依然正常工作。一个5台机器集群的服务，能够对2台机器挂掉的情况下进行容灾。如果一个由6台服务器构成的集群，同样只能挂掉2台机器。因此，5台和6台在容灾能力上并没有明显优势，反而增加了网络通信负担。系统启动时，集群中的server会选举出一台server为 Leader，其它的就作为 follower（这里不考虑 observer 角色）。
结论：之所以要满足这样一个等式，是因为一个节点要成为集群中的 leader，需要有超过集群中过半数的节点支持，这个涉及到 leader 选举算法。同时也涉及到事务请求的提交投票。