微服务实战系列之ZooKeeper（中）

前言

昨日博主的第一篇

ZooKeeper

，对它自身具备的能力做了初步介绍。书接上文，马不停蹄，我们继续挖掘它内在的美，充分把握它的核心与脉络。

揭秘ZooKeeper

Q：集群一致性协同是如何进行的

我们讲到分布式，一般是在集群环境下实现的。以ZooKeeper为例，它是如何保障集群环境下的成功运转呢？

1. 节点角色

通过上图，我们认识一下ZooKeeper的3类节点：

• Leader节点 Leader作为ZooKeeper的领袖，有着举足轻重的作用。它是ZooKeeper集群环境如何稳定运行的关键，主要负责读写和调度等核心工作。如果它宕机了，一致性调度从此冷却，整个集群将面临群龙无首的局面，直至系统瘫痪。
• Follower节点 作为随从节点，主要负责客户端的读操作，如果遇到写申请， 需要转发Leader节点完成，自身不做任何处理。如Leader宕机，会立即参与Leader的选举，具有投票权。
• Observer节点 作为候选角色，Observer为提升整个集群的执行效率提供一定帮助，但仅限于读操作。不参与写，不参与Leader的选举。

了解3类节点后，我们大概知道每个Server（Node）是如何执行客户端申请以及Server集群内部是如何完成最终一致性协同的过程。

比如Client对任一类节点发起读操作，则每个节点均可立即返回本地数据，如此便提高了响应性能；
比如Client对Follower节点发起写操作，则它会写命令转交Leader完成，最后由Leader完成写操作和数据同步；
比如Leader发生宕机，则

Follower们

立即启动选举，任命新的Leader。而Observer完全可以

“袖手旁观，置之不理”

，此刻真是

“开心开心极了...”

2. 基础协议

为了实现上述一致性数据同步，ZooKeeper基于

ZAB（Zookeeper Atomic Broadcast 原子广播协议）

完成的。

ZAB

准确来讲提供了一套完整的数据同步消息机制。（无论哪类节点）从接收客户端请求到客户端收到实时数据，并实现集群内部数据写操作的一致性，均是通过ZAB机制完成的。

通过上图，我们了解到，Leader负责处理写请求，如其他节点接收到写请求，需转发Leader完成。那么Leader收到请求后，如何继续工作呢？

1. 发布全局唯一事务申请zxid（zxid是64位的Long类型）；
2. 所有的Follower均对此申请进行反馈；
3. Leader如收到反馈过半，则执行写提交，最后完成集群同步；

Q：集群选举如何进行的

我们都知道Leader至关重要，是维持ZooKeeper的集群健康运转的大脑。但天有不测风云，即使

7*24

高可用高可靠，也难免百密一疏。如果Leader真的宕机了？ 如何维持集群秩序呢？

接下来，博主带着各位盆友，继续揭秘ZooKeeper中

Leader

的选举过程。

既然有选举，就有投票，有投票，就有候选人，有投票人。那么候选人和投票人是怎么产生的，最终谁才能胜任？

在正式讲解选项过程前，我们先了解一些基础知识。

1. 节点状态

在ZooKeeper集群中，涉及4中状态：
节点状态简介LOOKING寻 找 Leader 状态，即开始选举的初始状态FOLLOWING跟随者状态，表明当前节点为FollowerLEADING领袖状态，表明当前节点为LeaderOBSERVING观察者状态，表明当前节点为Observer

2. 节点ID

我们在搭建ZooKeeper集群时，一般需要为每个Server（Node）标识一个唯一的编号（从小到大，比如1.2.3，以此类推）。

这个ID一般记录在每个ZooKeeper Server中的数据文件中，安装时指定。

3. 奇数

ZooKeeper集群信仰奇数，为什么? 因为有

“过半才OK”

的理念。
所以我们在搭建集群时，务必按要求配置，否则ZooKeeper可能无法正常工作哦。

4. 投票选举Leader

选举场景简介启动时选择此刻集群中的节点ID最大者投票。当然开始时，均可为自己投票，实时更新状态故障恢复时根据ZXID顺序，优先执行，并选择此刻集群中的节点ID最大者投票
投票结束后，收到票数过半者则当选新一任

Leader

，其他节点自动更新为

Follower

，而Observer自必不说，全程不参与。

到此为止，我们具备了以上基础知识后，继续回看上图，是不是可以理解了？

结语

博主通过揭秘

ZooKeeper

内在的核心逻辑，剖析它是如何完成我们想象中的职责和工作的。通过以上内容，我们可以发现，无论是什么协议或算法，均服务于某个业务和技术场景。所以感谢前辈们的辛勤耕耘，才有ZooKeeper的用武之地。

历史回顾

• 微服务实战系列之ZooKeeper（上）
• 微服务实战系列之MQ
• 微服务实战系列之通信
• 微服务实战系列之J2Cache
• 微服务实战系列之Cache（技巧篇）
• 微服务实战系列之MemCache
• 微服务实战系列之EhCache
• 微服务实战系列之Redis
• 微服务实战系列之Cache
• 微服务实战系列之Nginx（技巧篇）
• 微服务实战系列之Nginx
• 微服务实战系列之Feign
• 微服务实战系列之Sentinel
• 微服务实战系列之Token
• 微服务实战系列之Nacos
• 微服务实战系列之Gateway
• 微服务实战系列之加密RSA
• 微服务实战系列之签名Sign