02-zookeeper总结

Zookeeper总结

zookeeper主要是解决分布式环境下的服务协调问题而产生的。zookeeper用zab协议做集群Leader选举，使用分布式事务实现数据的的一致性。其实现机制的整合呈现给我们了一个实现了弱顺序一致性分布式协调服务。

zookeeper的集群

集群角色

Leader角色

Leader无武器是整个zookeeper集群的核心，主要的工作任务有两项：

• 事务请求的唯一调度和处理者，保证集群事务处理的顺序性。
• 集群内部各服务器的调度者。

Follower角色

Follower角色的主要职责是：

• 处理客户端非事务请求、转发事务请求给leader服务器。
• 参与事务请求Proposal的投票（需要半数以上服务器通过才能通知Leader Commit数据；Leader发起的提案，要求Follower投票）
• 参与Leader选举的投票

Observer角色

Observer是zookeeper3.3开始引入的一个全新的服务器角色，从字面来理解，该角色充当了观察者的角色。

观察zookeeper集群中的最新状态变化并将这些状态变化同步到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集群，能够在挂掉一台机器后依然正常工作。一个5台机器集群的服务，能够在2台机器挂掉的情况下进行容灾。如果一个有6台服务器构成的集群，同样只能挂掉2台机器。因此，5台和6台在容灾能力上并没有明显优势，反而增加了网络通信负担。系统启动时，集群中的server会选举出一台server为Leader，其他就作为Follower（这里先不考虑Observer角色）。

之所以要满足这样一个等式，是因为一个节点要称为集群中的Leader，需要有超过集群中过半数的节点支持，这个涉