一文详解 RocketMQ 如何利用 Raft 进行高可用保障

最新推荐文章于 2025-05-08 18:39:31 发布

阿里巴巴中间件

最新推荐文章于 2025-05-08 18:39:31 发布

阅读量1.1k

点赞数 15

CC 4.0 BY-SA版权

文章标签： rocketmq

本文链接：https://blog.csdn.net/weixin_39860915/article/details/141441321

前言

Aliware

Apache RocketMQ 自诞生以来，因其架构简单、业务功能丰富、具备极强可扩展性等特点被众多企业开发者以及云厂商广泛采用。历经十余年的大规模场景打磨，RocketMQ 已经成为业内共识的金融级可靠业务消息首选方案，被广泛应用于互联网、大数据、移动互联网、物联网等领域的业务场景。由于其业务场景愈加丰富，在工业界的使用率日益提高，开发者们也必须更完善地考虑 RocketMQ 的可靠性、可用性。

由于 RocketMQ 底层实际上是一种基于日志的存储系统，而前人为了避免这种存储系统中单个机器可能出现的数据丢失、单点故障等问题，已经有了相对成熟的解决方案——例如同时复制数据到多个机器上。在这个过程中，需要解决的问题便被简化了：如何保证多个机器上的数据是一致的，而且这种一致性强大到可以对抗宕机、脑裂等问题。而这些问题，可以通过分布式一致性算法来彻底解决。

在开源的 Apache RocketMQ 中，我们已经引入了 DLedger^[^2]和 SOFAJRaft^[^3]来作为 Raft^[^4]算法的具体实现，以支撑系统高可用。本文将介绍 RocketMQ 如何利用Raft（一种简单有效的分布式一致性算法）进行高可用的保障。

分布式一致性算法：Raft

Aliware

共识（Consensus）是分布式系统中实现容错的一个基本问题。它指的是在一个系统中，多个服务器需要就某些值达成一致的意见。一旦它们对一个值做出了决定，这个决定就是不可变更的^[^1]。典型的共识算法能够在多数服务器可用的情况下继续运行；比如说，在一个有 5 台服务器的集群中，即使有 2 台服务器宕机，整个集群依然能够正常运作。如果宕机的服务器数量超过半数，集群就无法继续正常运行了（但它也绝不会返回错误的结果）。

业界比较有名的分布式一致性算法是 paxos^[^12]，不过可惜的是它比较晦涩难懂，难懂的代价就是很少有人能掌握它然后基于它做出可靠的实现。不过幸好 Raft 及时出现，它易于理解，并且已经有非常多的业界使用先例，比如 tikv、etcd 等。

这是 Raft 的原始论文，详细描述了 Raft：《In Search of an Understandingable Consensus Algorithm》^[^4]。本文的略短版本在 2014 年 USENIX 年度技术会议上获得了最佳论文奖。有意思的是，在论文的 Abstract 中，第一句话便是：Raft is a consensus algorithm for managing a replicated log.

在英文中，log 不仅有“日志”的意思，还有“木头”的意思，一组"replicated log"便组成了木筏，这和 Raft 的英文原意不谋而合。而且，Raft 的主页中，也采用了三根木头组成的筏作为 logo（如图 1）。当然，对 Raft 更正式的解释还是这些单词的首字母缩写：Re{liable | plicated | dundant} And Fault-Tolerant. 也就是 Raft 被提出时要解决的问题初衷。

图 1：Raft 主页标题后附的头图

Raft 算法是一种为了管理复制日志的共识算法，它将整个共识过程分解为几个子问题：领导者选举、日志复制和安全性。整个 Raft 算法因此变得易理解、易论证、易实现，从而让分布式一致性协议可以较为简单地实现。Raft 和 Paxos 一样，只要保证 n/2+1 节点即多数派节点正常就可以对外提供服务。

在 Raft 算法中，集群中的每个节点（服务器）可以处于以下三种状态之一：

a. Follower（跟随者）：这是所有节点的初始状态。它们被动地响应来自领导者和候选者的请求。

b. Candidate（候选者）：当跟随者在一段时间内没有收到来自领导者的消息时，它们会成为候选者，并开始选举过程以成为新的领导者。

c. Leader（领导者）：集群中的管理节点，负责处理所有客户端请求，并将日志条目复制到其他节点。

Raft 算法通过任期的概念来分隔时间，每个任期开始都会进行一次领导者选举。任期是一个递增的数字，每次选举都会增加。如果跟随者在“选举超时”之内没有收到领导者的心跳，它会将自己的任期号加一，并转变为候选者状态来发起一次领导者选举。候选者首先给自己投票，并向其他节点发送请求投票的 RPC。如果接收节点在当前任期内还没有投票，它会同意投票给请求者。

如果候选者在一次选举中从集群的大多数节点获得了选票，它就会成为领导者。在此过程中生成的任期号用于节点之间的通信，以防止过时的信息导致错误。例如，如果节点收到任期号比自己小的请求，它会拒绝该请求。

极端情况下集群可能会出现脑裂或网络问题，此时集群可能会被分割成几个互不通信的子集。不过由于Raft算法要求一个领导者必须拥有集群大多数节点的支持，这保证了即使在脑裂的情况下，最多只有一个子集能够选出一个有效的领导者。

Raft 通过日志复制来保持节点间的一致性。对于一个无限增长的序列 a[1, 2, 3…]，如果对于任意整数 i，a[i] 的值满足分布式一致性，这个系统就满足一致性状态机的要求基本上所有的真实系统都会有源源不断的操作，这时候单独对某个特定的值达成一致显然是不够的。为了让真实系统保证所有的副本的一致性，通常会把操作转化为 write-ahead-log(WAL)。然后让系统中所有副本对 WAL 保持一致，这样每个副本按照顺序执行 WAL 里的操作，就能保证最终的状态是一致的，如图 2 所示。

图 2：如何通过日志复制来确保节点间数据一致。阶段一为 Client 向 leader 发送写请求，阶段二为 Leader 把‘操作’转化为 WAL 并复制，阶段三为 Leader 收到多数派应答，并将操作应用到状态机

领导者在收到客户端的请求后，会先将请求作为新的日志条目追加到它的日志中，然后并行地将该条目复制到其他节点。只有当大多数节点都写入了这个日志条目，领导者才会将该操作提交，并应用到它的状态机上，同时通知其他节点也提交这个日志条目。因此，Raft 确保了即使在领导者崩溃或网络分区的情况下，也不会有数据丢失。任何被提交的日志条目都保证在后续的任期中也存在于任意新的领导者的日志中。

简单来说，Raft 算法的特点就是 Strong Leader：

a. 系统中必须存在且同一时刻只能有一个 Leader，只有 Leader 可以接受 Clients 发过来的请求；

b. Leader 负责主动与所有 Followers 通信，负责将“提案”发送给所有 Followers，同时收集多数派的 Followers 应答；

c. Leader 还需向所有 Followers 主动发送心跳维持领导地位（保持存在感）。

一句话总结 Strong Leader: "你们不要 BB! 按我说的做，做完了向我汇报!"。另外，身为 Leader 必须保持一直 BB（heartbeat）的状态，否则就会有别人跳出来想要 BB 。

为了更直观的感受到 Raft 算法的运行原理，笔者强烈推荐观看下面网站中的演示。它以动画的形式，非常直观地展示了 Raft 算法是如何运行的，以及如何应对脑裂等问题的：https://thesecretlivesofdata.com/raft/