关于zookeeper的集群部署可以直接看我之前写的这篇文章总结:

https://www.jianshu.com/p/a5aee219052b

然后下面我来讲一下zookeeper集群中存在的一些角色，以及这些角色存在的意义:

image.png

1.Leader角色

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

1.事务请求的唯一调度和处理者，保证集群事务处理的顺序性。
2.集群内各个服务的调度者。

在zookeeper中，客户端会随机连接到zookeeper集群中的一个节点，如果是读请求，就会直接从当前节点读取数据，如果是写请求(这里应该说是事务请求，也就是涉及事务操作的增删改)，如果该节点不是leader角色，就会转发给leader角色，由leader角色负责处理事务，然后leader就会广播事务，只有超过半数的节点写入数据成功，那么写请求才会被提交。

leader角色在整个集群中是唯一的，这里zookeeper设计会考虑到单点故障问题，如果leader宕机了，那么就会通过选举算法进行选举出新的leader出来，然后这个节点会进行重启。那么如何保证数据的一致性我们后面再来说。当leader宕机会由Observer通过心跳检测到，一般设置为两秒。这时候就会通过zab协议进行选举新的leader出来，然后进行崩溃恢复。

关于zab协议如何在zookeeper整个集群中发挥作用以及leader宕机后和如何选举可以看我写的另外两篇文章:

//todo
https://www.jianshu.com/p/c93906a9a860

这里关于怎么leader怎么处理各个节点数据一致性，保证分布式事务的成功可以参考以下这篇文章==
https://www.jianshu.com/p/948d843b0489
这一篇是扩展，可以不看。
https://www.jianshu.com/p/65cb90b169d7

2.Follow角色

follow角色的主要指责就是如下:

1.处理客户端非事务请求、转发事务请求给leader服务器。
2.参与事务的Proposal投票(需要半数以上服务器通过才能通知leader commit数据)。
3.参与leader选举的投票。

3.Observer 角色

Observer 是 zookeeper3.3 开始引入的一个全新的服务器角色，从字面来理解，该角色充当了观察者的角色。 观察 zookeeper 集群中的最新状态变化并将这些状态变化同步到 observer 服务器上。Observer 的工作原理与follower 角色基本一致，而它和 follower 角色唯一的不同在于 observer 不参与任何形式的投票，包括事物请求Proposal 的投票和 leader 选举的投票。

简单来说，observer服务器只提供非事物请求服务，通常在于不影响集群事物处理能力的前提下提升集群非事物处理的能力。

基本架构

1 每个Server在内存中存储了一份数据；
2 Zookeeper启动时，将从实例中选举一个leader（Paxos协议）；
3 Leader负责处理数据更新等操作（Zab协议）；
4 一个更新操作成功，当且仅当大多数Server在内存中成功修改

关于集群部署的个数原理

通常 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，需要有超过及群众过半数的节点支持，这个涉及到 leader 选举算法。同时也涉及到事务请求的提交投票。

崩溃恢复和如何保持数据一致性

关于这点，zookeeper主要使用通过使用支持奔溃恢复的原子广播协议ZAB协议来维护的，关于之前我们就说过了，在集群中，事务的请求主要是leader去处理的，leader会广播事务，只要有超过半数的节点写入成功，该写请求就会被提交，使用类似2pc提交的方式。

leader选举
可以看我这篇文章已经总结的非常详细了:

如何崩溃恢复和如何保持数据一致性我发现一时半会讲不完，我会在下面这篇博客下面去讲zab协议的同时去讲如何保持。

https://www.jianshu.com/p/c93906a9a860

感谢您阅读，整理不易，帮我点个赞哈，谢谢。
如果对文章部分还有什么见解或者疑惑，可私信我