主从选举机制，架构高可用性的不二选择

系列文章目录

当Dubbo遇到高并发：探究流量控制解决方案

---

前言

随着现代数据处理量和对稳定性要求的水涨船高，高并发，高可用，高性能逐渐成为Java程序员的日常，但是这种架构暗藏很多难点，如果你对这种架构还有很多疑惑，可以直接锁定本栏目，会持续推出有关三高架构的内容
本文主要分析现代三高架构中的一个经典集群结构————主从模式，并分析一些常见框架在集群上的异同

作者简介：战斧，从事金融IT行业，有着多年一线开发、架构及管理经验；爱好广泛，乐于分享，致力于创作更多高质量内容
本文收录于 JAVA架构，有需要者，可直接订阅专栏实时获取更新
高质量专栏 RabbitMQ、Spring全家桶 等仍在更新，欢迎指导
Zookeeper Redis kafka docker netty等诸多框架，以及架构与分布式专题即将上线，敬请期待

---

一、集群与主从

计算机集群简称集群，是一种计算机系统， 它通过一组松散集成的计算机软件或硬件连接起来高度紧密地协作完成计算工作。在某种意义上，他们可以被看作是一台计算机。需要注意的是，一般我们在架构上讲的集群是从业务角度看的，只有具备同种功能的多台机器才算一个集群。

我们都知道，当前Java的架构体系在使用的大部分程序或中间件，都具有组成集群的能力，并且也推荐以集群模式去部署，比如Redis

之所以大家都采用了集群的模式，主要是因为其强大的作用和优势，我们先看看集群的几个作用：

• 提高计算能力：集群可以同时运行多个计算任务，从而提高整个系统的计算能力和性能。

• 提高可用性：通过在多个计算节点上分配和复制数据和应用程序，集群可以提高整个系统的可用性和容错能力，即使某个节点发生故障，也可以在其他节点上继续运行。

• 提高可扩展性：集群可以根据需要添加或删除节点，从而提高系统的可扩展性和灵活性，使其能够适应不同的工作负载和需求。

• 分布式计算：集群可以支持分布式计算，将大型计算任务分割成多个子任务并在多个节点上并行计算，从而加速计算速度。

• 负载均衡：通过将负载分配到不同的节点上，集群可以实现负载均衡，避免某个节点过载而导致整个系统崩溃。

而主从模式是集群模式的一种，是指在一个集群中，有一个主节点和多个从节点。主节点负责协调和控制整个集群的工作（有的组件主节点也会执行任务），而从节点负责处理具体的请求和任务。主节点可以进行数据的分发、负载均衡、任务调度、故障检测和恢复等操作，从节点可以并行处理任务，提高计算效率和性能

如上图，master即主节点，slave即从节点。主从模式常用于分布式数据库、分布式缓存和分布式计算等场景。支持主从模式的常见框架有Mysql 、Zookeeper、Redis等

二、主从选举问题

上一章我们提到了主从模式。我们需要知道主从模式的设计一般都用于存储类的组件，主要是需要保证数据的高可用与一致性，且由于该模式的数据冗余备份，对于异常场景的数据恢复也大有裨益，那么采用了主从模式的组件，现在有哪些难点呢？其中，首当其冲的就是高可用问题

1. redis 哨兵选取（Raft）

Sentinel（哨兵）是Redis的高可用性解决方案。

即由一个或多个Sentinel实例（instance）组成的Sentinel系统 （system）可以监视任意多个主服务器，以及这些主服务器属下的所有 从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务 器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替 已下线的主服务器继续处理命令请求

哨兵功能主要有以下三个责任

• 监控
  监控是指哨兵进程运行时，周期性给所有主从库发送PING命令，检测他们是否仍然在线运行。
  从库没有在规定时间内响应哨兵的PING命令，哨兵就会把它标记为"下线状态"；
  主库没有在规定时间呢响应哨兵的PING命令，哨兵就会判定主库下线启动选主流程。
• 选主
  哨兵在主库挂了以后，按照一定规则从从库中选出作为新的主库。
• 通知
  哨兵将选出的新主库连接信息发给其他从库，让他们执行replicaof命令，和新主库建立连接，复制数据。同时，哨兵会把新主库的连接信息通知给客户端，让它们将操作请求发送给新主库上。

其中，面试提及最多的的就是选举流程，我们可以仔细看看该流程
Sentinel 选举主节点的过程如下：

1. Sentinel 监测到某个主从系统的主节点不可达；
2. Sentinel 向其他 Sentinel 节点询问当前的主节点状态，并提出自己成为哨兵主节点的请求；
3. 如果 Sentinel 节点的数量达到了 quorum（quorum=Sentinel 节点数/2+1），则开始选举；
4. Sentinel 节点按照一定的优先级进行选举，优先级高的节点更有可能被选为新的哨兵主节点；
5. 如果没有节点获得多数投票，则重新开始选举，直至选出新的哨兵主节点。
6. 哨兵主节点开始为主从系统选取Leader，此时又遵循下列规则

过滤故障的节点
选择优先级slave-priority最大的从节点作为主节点，如不存在则继续
选择复制偏移量（数据写入量的字节，记录写了多少数据。主服务器会把偏移量同步给从服务器，当主从的偏移量一致，则数据是完全同步）最大的从节点作为主节点，如不存在则继续
选择runid（redis每次启动的时候生成随机的runid作为redis的标识）最小的从节点作为主节点

2. zookeeper Zab协议崩溃恢复

与redis相比，zk没有哨兵机制，而是使用了Zab协议，zab协议有两个方面

• 崩溃恢复
• 消息广播

我们这里仅谈崩溃恢复，即当zk的主节点失效时，新的主节点，是由该主从系统中的从节点相互协商及投票形成的，而且各节点默认是选举自己，并把信息告知其他节点。

由于每个节点都自带投票箱，能根绝自己投票箱的票数情况，进行变卦，也就是重新投票给别的节点，如此往复，直到大部分节点的投票箱都选的某个节点，然后该节点即为新的主节点。更加具体的流程，以及选举的优先级判断，可通过下图了解

这其中，作为选举规则，zxid 和 epoch 其实是关键。其实，在实现上，这两者是拼接起来的，即两者合在一起（因此有的说法就只说 ZXID），实际上是一个 64 位的数字，高 32 位是 epoch（ 时期; 纪元;）用来标识 leader 周期，如果有新的 leader 产生出来，epoch会自增；低 32 位用来递增计数，就是每向系统做一次数据更新（增删改）的请求，就会递增

zxid 初始化是 0，也就是这样

每一次写请求都会增加后 32 位，假设现在进行了 10 次写请求（无论该请求有没有真的修改到数据），zxid 就会变成这样

当进行一次选举的时候，前 32 位就会增加 1，并且清零后 32 位

除了选举以外，当后 32 位彻底用完（变成全 1，也就是 ZK 正常执行了 2^32 - 1 次写请求都没进行过一次选举）也会让前 32 位增加 1，相当于

3. kafka Controller选择

kafka的主从用法和上面的并不一样，一般的主从模式，主节点(leader)负责更新，从节点(follower)负责查询，从而进行分流，然而kafka的从节点本身并不承担查询的功能，仅仅是作为备份存在，且根据备份的进度分为

• ISR(in-sync replica):保持同步的副本
• OSR(out-sync replica):未同步的副本

而要实现保持同步，Producer发送消息时，消息只有被全部写到了ISR中，才会被视为已提交状态
-

如果ISR中没有副本，只能从OSR中选举一个作为Leader，但是OSR中副本的数据可能会存在数据丢失，所以这个功能是可以配置的，默认是打开的。

配置项：
unclean.leader.election.enable = true/false

同样的，kafka的选举方式也有所不同，它的选举是由 Controller 一手操控的，当检测到主节点挂了，Controller能够从ISR里任选一个重新作为主节点，那么Controller又是怎么来的，当Controller所在的机器挂了，又当如何呢？

实际上，Kafka的信息管理依赖于内置的zookeeper，所谓的Controller也只是一个注册在zookeeper上的Broker(可认为是某台服务器)，只不过需要负责一些额外的工作(追踪集群中的其他Broker，并在合适的时候处理新加入的和失败的Broker节点、Rebalance分区、分配新的leader分区等)。值得注意的是：Kafka集群中始终只有一个Controller Broker。

而至于Controller 是怎么选出来的？其实并不是选出来的，而是得益于zookeeper的分布式锁的应用（最先在Zookeeper上创建临时节点/controller），由各Broker竞争，最终只有一个成功注册了，那么该Broker就是新的Controller

如果Controller 断连，需要重新竞争一个Controller时，kafka会在epoch numbe上加1，表示新的Controller诞生，此时即使原Controller恢复，也不再拥有Controller的权力， epoch number记录在Zookeepr的一个永久节点controller_epoch

4. 选举方式总结

• Redis的选举机制是基于Raft协议，用于选举哨兵(Sentinel)集群中的主节点，再由该主节点为主从系统选出主节点；
• Zookeeper的选举机制是基于Zab协议（选举模式基于Paxos），用于选举领导者节点。
• Kafka的选举机制是基于Zookeeper的分布式锁，竞争出出控制器节点Controller，然后Controller从ISR集合中选一个作为主节点；

不难看出，从一堆从节点中选择一个主节点分为两种情况：

1. 一种就是从节点（或部分从节点）有着强一致协议，即这些节点的数据与主节点保持一致。这样随便从里面选一个出来就可以作为主节点
2. 如果节点间一致性较弱，也就是说从节点可能落后于主节点，此时就需要选举出数据最接近的从节点，这种选举可以由从节点之间自行选出，也可以由第三方来指出。
3. 如果涉及到第三方，即第三方来决定谁做主节点，那么第三方本身也要支持高可用和选举，如redis的Sentinel系统，zookeeper的Controller
4. 一群节点间的选举，本质是共识算法，目前通用的共识算法为Raft与Paxos