【Zookeeper】集群模式：架构设计猜想

古城微笑少年丶 2022-11-03 15:30 177阅读 0赞

基于Zookeeper本身的一个设计目标，zookeeper 主要是解决分布式环境下的服务协调问题 而产生的，我们来猜想一下，如果我们要去设计一个zookeeper，需要满足那些功能呢？

**防止单点故障**

若所有Zookeeper节点都以单机形式存在，那么宕机后系统就停止服务了，而为了保证高可用，常见解决单点问题的办法就是**集群**。这个集群需要满足那些功能？

1.  集群中要有主节点和从节点（也就是集群要有角色）
2.  集群要能做到数据同步，当主节点出现故障时，从节点能够顶替主节点继续工作
3.  主节点挂了以后，从节点如何接替成为主节点？ 是人工干预？还是自动选举

### 1.主从模型 ###

接着上面那个结论再来思考，如果要满足这样的一个高性能集群，我们最直观的想法应该是， 每个节点都能接收到请求，并且每个节点的数据都必须要保持一致。要实现各个节点的数据 一致性，就势必要一个leader节点负责协调和数据同步操作。这个我想大家都知道，如果在这样一个集群中没有leader节点，每个节点都可以接收所有请求，那么这个集群的数据同步的复杂度是非常大。

所以，当客户端请求过来时，需要满足，事务型数据和非事务型数据的分开处理方式，就是 leader 节点可以处理事务和非事务型数据。而follower节点只能处理非事务型数据。原因是， 对于数据变更的操作，应该由一个节点来维护，使得集群数据处理的简化。同时数据需要能 够通过leader进行分发使得数据在集群中各个节点的一致性。

*  主节点（Leader），Leader服务器是整个zookeeper集群的核心，主要的工作任务有两项
    
     *  接收事务请求（写请求，增删改）-> 处理 -> 给子节点数据同步
     *  接收非事务请求，并协调各节点
 *  从节点（Follower），Follower角色的主要职责是：
    
     *  处理非事务请求（读请求，查询），起到负载均衡作用
     *  转发事务请求给 Leader -> 参与事务请求的Proposal投票（Leader提案，Follower投票半数以上通过，Leader才能commit数据）-> 待Leader处理完事务请求后，进行数据同步
     *  参与Leader选举的投票

整体架构图如下：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]

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

### 2.数据同步 ###

在分布式系统中，每一个机器节点虽然都能够明确知道自己进行的事务操作过程是成功和失败，但是却无法直接获取其他分布式节点的操作结果。所以当一个事务操作涉及到跨节点的时候，就需要用到分布式事务，那么如何保证跨节点数据处理一致性？

答：采用 2PC（Two Phase Commitment）协议或者 3PC协议。

> 关于 2PC 提交请看这篇：[【分布式事务】X/OpenDTP事务模型、CAP/Base理论][X_OpenDTP_CAP_Base]…

### 3.选举机制 ###

通常 zookeeper 是由 2n+1 台 server 组成，每个 server 都知道彼此的存在。每个 server 都 维护的内存状态镜像以及持久化存储的事务日志和快照。

对于 2n+1 台 server，只要有 n+1 台（大多数）server可用，整个系统保持可用。我们已经了解到，一个zookeeper集群如果要对外提供可用的服务，那么集群中必须要有过半的机器正常工作并且彼此之间能够正常通 信，基于这个特性，如果向搭建一个能够允许F台机器down掉的集群，那么就要部署2\*F+1 台服务器构成的 zookeeper 集群。

> 之所以要满足这样一个等式，是因为一个节点要成为集群中的 leader，需要有超过及群众过 半数的节点支持，这个涉及到leader选举算法。同时也涉及到事务请求的提交投票

因此 3 台机器构成的 zookeeper 集群，能够在挂掉一台 机器后依然正常工作。一个5台机器集群的服务，能够对2台机器怪调的情况下进行容灾。 如果一台由6 台服务构成的集群，同样只能挂掉2 台机器。因此，5 台和 6台在容灾能力上并没有明显优势，反而增加了网络通信负担。系统启动时，集群中的 server 会选举出一台 server为Leader，其它的就作为follower（这里先不考虑observer角色）。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MzkzNTkyNw_size_16_color_FFFFFF_t_70_pic_center]: /images/20221023/dd26f65fa7f44377bcecab560cc963dc.png
[X_OpenDTP_CAP_Base]: https://blog.csdn.net/weixin_43935927/article/details/109897297