初识ZooKeepe和ZooKeepe集群角色组成说明

ZK的主要作用如下：

1. 协议地址的维护；
2. 负载均衡机制；
3. 服务动态上下线感知；

为了维持ZK的高可用，一般会搭建集群。通常在分布式系统中，构成一个集群的每一台机器都有自己的角色，最典型的集群模式就是Master/Slave模式（主备模式）。在这种模式中，我们把能够处理所有写操作的机器称为Master机器，把所有通过异步复制方式获取最新数据，并提供读服务的机器称为Slave机器。而在ZK集群中有三种角色：follower、leader、observer。

ZK集群中的所有机器通过一个leader选举过程来选定一台被称为“leader”的机器，leader服务器为客户端提供读和写服务。除leader外，其他机器包括follower和observers都能够提供读服务，唯一的区别在于，observer机器不参与leader选举过程，也不参与写操作的“过半写成功”策略，因此observer可以在不影响写性能的情况下提升集群的读性能。

在 zookeeper 中，客户端会随机连接到 zookeeper 集群中的一个节点，如果是读请求，就直接从当前节点中读取数据，如果是写请求，那么请求会被转发给 leader 提交事务，然后 leader 会广播事务发给除了observer的每一个节点，只要有超过半数节点写入成功，那么写请求就会被提交（类 2PC 事务），成功后会同步给observer。

leader 角色 

leader 服务器是整个ZK集群的核心，负责响应所有对ZooKeeper状态变更的请求。它会将每个状态更新请求进行排序和编号，以便保证整个集群内部消息处理的FIFO。主要的职责： 
1.处理事务请求（添加、修改、删除）和非事务请求，也是事务请求的唯一调度和处理者，能够保证集群事务处理的顺序；
2.集群内部各服务器的调度者；

follower 角色

从角色名字上可以看出，follower服务器是ZooKeeper集群状态的跟随者，主要的职责：
1.处理客户端非事务请求，如果请求是事务请求，会转发事务请求给 leader 服务器；
2.参与事务请求 Proposal 的投票（leader发起的提案，要求follower投票，需要半数以上follower节点通过，leader才会commit数据）；
3.参与 Leader 选举的投票；

observer 角色
observer 是 ZooKeeper3.3 开始引入的一个全新的服务器角色，从字面来理解，该角色充当了观察者的角色。观察ZooKeeper集群中的最新状态变化并将这些状态变化同步到observer服务器上。observer的工作原理与follower角色基本一致，而它和follower 角色唯一的不同在于observer不参与任何形式的投票，包括事务请求Proposal的投票（Zookeeper的Znode变更是要过半数投票通过，随着机器的增加，由于网络消耗等原因必然导致投票成本增加，从而导致写性能的下降）和leader选举的投票。只是简单的接收投票结果，因此我们增加再多的observer，也不会影响集群的写性能。除了这个差别，其他的和follower基本上完全一样。例如：Client都可以连接到他们，并且都可以发送读写请求给他们，收到写请求都会上报到leader。简单来说，observer服务器只提供非事物请求服务，通常在于不影响集群事务处理能力的前提下提升集群非事物处理的能力。所以observers可以在不伤害写性能的情况下扩展ZooKeeper。

因为它不参与投票，所以他们不属于ZooKeeper集群的关键部位，即使他们failed，或者从集群中断开，也不会影响集群的可用性。根据observer的特点，我们可以使用observer做跨数据中心部署。如果把leader和follower分散到多个数据中心的话，因为数据中心之间的网络的延迟，势必会导致集群性能的大幅度下降。使用observer的话，将observer跨机房部署，而leader和follower部署在单独的数据中心，这样更新操作会在同一个数据中心来处理，并将数据发送的其他数据中心（包含observer的），然后Client就可以在其他数据中心查询数据了。但是使用了observer并非就能完全消除数据中心之间的延迟，因为observer还得接收leader的同步结果合observer有更新请求也必须转发到leader，所以在网络延迟很大的情况下还是会有影响的，它的优势就为了本地读请求的快速响应。

集群组成

通常 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 选举算法。同时也涉及到事务请求的提交投票。

补充：

在ZooKeeper的实现中，每一个事务请求都需要集群中过半机器投票认可才能被真正应用到ZooKeeper的内存数据库中去，这个投票与统计过程被称为“Proposal流程”。

参考资料：

https://blog.csdn.net/fu123123fu/article/details/81193780

https://blog.csdn.net/mayp1/article/details/52026797