RocketMQ 在小米的多场景灾备实践案例

作者：邓志文、王帆

01 为什么要容灾？

在小米内部，我们使用 RocketMQ 来为各种在线业务提供消息队列服务，比如商城订单、短信通知甚至用来收集 IoT 设备的上报数据，可以说 RocketMQ 的可用性就是这些在线服务的生命线。作为软件开发者，我们通常希望服务可以按照理想状态去运行：在没有Bug的前提下，系统可以提供正常的服务能力。

但现实的运维经验告诉我们这是不可能的，硬件故障是非常常见的问题，比如内存故障、磁盘故障等，甚至是机房相关的故障（专线故障、机房拉闸等）。因此我们需要对数据进行备份，使用多副本的方式来保证服务的高可用。Apache RocketMQ 设计上就支持多副本、多节点容灾，比如 Master-Slave 架构、DLedger 部署模式。

在小米内部，因为是面向在线业务，服务的恢复速度至关重要，而基于 Raft 协议的 DLedger 模式可以实现秒级 RTO，因此我们在 2020 年初选用了 DLedger 架构作为基本的部署模式（在 5.0 中，主从模式也可以做到自动 failover）。支持机房灾备需要增加额外的成本，下面我将用三个灾备部署的实践案例，讲解小米如何在成本和可用性的取舍上去支持灾备。

02 怎么去做容灾？

单机房高可用

实际在使用中，有许多业务是不需要机房级别容灾的，只要能够做到单机房高可用即可。Apache RocketMQ 本身就是分布式的消息队列服务，可以很好的做到同机房多节点高可用，下面主要分享下小米在权衡成本、可用性的前提下，如何去做部署架构的升级优化。

我们知道在 Raft 协议中，一般配置三个节点，利用机器冗余 + 自动选主切换来实现高可用的目标。因此在小米引入 RocketMQ 之初，单 Broker 组均部署三个 Broker 节点。同时为了保证集群中始终存在 Master 节点，我们一般会至少部署两个 Broker 组，一个简单的部署架构图如下：

可以说是一个很基本的部署架构，在单个机房中，通过多副本、多Broker组做到了单机房容灾。但不难发现，这样做有一个很严重的问题：资源浪费。RocketMQ 的从节点只有在客户端读取较旧的数据时才会起到从读的作用，其他时候都只是单纯地作为副本运行，机器利用率只有33%，这是让人无法忍受的。

出于成本上的考虑，我们需要重新思考现有的部署架构，如何才能利用起来从节点呢？一个很简单的思路便是节点混布：在从节点也部署 Broker 进程，让其可以作为 Master 来提供服务。比较巧合的是，社区当时也提出了 Broker Container 的概念，方案的原理是在 RocketMQ Broker 之上抽象一个 Container 角色，Container 用来管理 Broker 的增删改查，以此来达到单台服务主机上运行多个 Broker 的目的，具体架构图如下所示：

可以看到，Container 作为进程运行，原本的 Broker 被抽象为 Container 的一部分，同样的 3 台机器上我们可以运行 9个 Broker 节点，组成三个 Broker组，每台服务主机上存在一个 Master 节点，使用 Container 对等部署 Broker 之后，每台服务主机都得到了利用，同样的机器数，理论上可以提供三倍的性能。

Container 是一种很好的部署思想：主从节点对等部署进而充分利用所有的机器。 我们尝试直接使用该方案，但遇到了一些问题：

1. Container 本质上是一个进程。不管其内运行了多少个 Broker ，我们只要对其进行重启操作，都会影响该 Container 内部 Broker 相关的所有 Broker 组，升级时会产生较为严重的影响；
2. Container 自己维护 Broker 的上下线，无法与小米内部部署工具结合使用。

因此 Container 并不适合小米内部，但受 Broker Container的启发，我们提出了另一种与之类似的部署方案——单机多实例。所谓单机多实例，即单台主机上部署多个 Broker 实例，服务主机就是我们的 Container，Broker 以进程的方式运行，这样各个 Broker 之前不会相互影响，同时也可以和内部部署工具完美结合。一个简单的部署架构如下所示：

至此，小米内部完成了 RocketMQ 部署架构的第一次升级，集群中的节点数直接减少了 2/3。在成本优化的前提上依然提供 99.95% 的可用性保障。

多机房容灾 -Ⅰ

随着业务的不断接入，一些业务提出了机房灾备的需求。机房故障的概率虽然极低，但是一旦出现，其带来的影响是非常大的。比如机房故障导致 RocketMQ 不可用，那么作为流量入口，将会影响到所有的依赖业务。

在多机房容灾上，我们结合内部其他服务的部署经验，先提出了多集群多活的方式，即每个可用区部署一个集群，提供多个集群供业务容灾，方案部署架构如下：

用户视角看到的是三个独立的集群，需要在相同的可用区部署客户端去读写同机房的 RocketMQ 集群。举个例子：可用区1的客户端正常情况下访问可用区1的 RocketMQ 集群Cluster-1，当Cluster-1故障时，用户需要手动更改客户端的连接地址来切换集群，进而将流量转移到其他机房的集群中。用户可以通过配置下发去热更新连接地址，也可以修改配置重启客户端来切换，但这一切的操作前提都是：需要业务感知到 RocketMQ 集群故障，手动触发才可以。

▷优点

• 不用跨区同步数据，低延时（P99写入10ms）高吞吐（单Broker组写入TPS达100K）
• 部署架构简单，稳定性高

▷缺点

• 集群需预留灾备buffer，确保故障时，存活集群可承载故障集群的全部流量
• 需要业务自己手动切换集群，不够灵活
• 若消费存在堆积，故障集群的消息将可能不会被消费，恢复后可消费

▷生产耗时

多机房容灾 -Ⅱ

可以看到，业务如果选择以上方式接入的话，需要做一定的适配工作，该方案适用于流量较大的业务接入。然而有一些业务希望可以低成本接入：不做适配，直接使用SDK接入，我们结合 DLedger 自动切换的特性，实验性的部署了机房故障服务自动 failover 的 模式，部署架构如下所示：

用户视角看到的就是一个独立的 RocketMQ 集群，使用 SDK 正常接入即可，无需任何适配。机房故障时依赖 DLedger 自动切主做流量切换。

▷优点

• 部署方便，充分利用 RocketMQ 的原生能力
• 自动选主，业务接入方便，无需业务手动切换流量

▷缺点

• 跨机房部署，容易受网络波动，集群抖动概率较大
• 跨机房部署，会增加写入延时，从而降低集群吞吐能力

▷生产耗时

多机房容灾 - PLUS

目前看来 RocketMQ 服务已经在小米完成了很好的落地，日消息量也达到了千亿规模，但我们仔细观察以上两个方案不难发现，虽然可以实现机房故障切换，但都有一定的缺点，简要概况如下：

• 多机房容灾 -Ⅰ：同机房请求，延时较低，但需业务手动切换集群
• 多机房容灾 -Ⅱ：自动切流、可消费历史数据，但对专线负载高，需三个Region才可部署

方案总是存在不够完美的地方，但不论作为服务的开发者还是业务使用者，其实都希望可以在实现以下几个目标的前提下做到灾备：

1）低成本：双Region可以完成部署；

2）低耗时：尽量同机房请求，减少网络耗时；

3）自动切流：机房故障时，可自动将流量切到正常的机房内。

为了实现以上的需求，我们从 RocketMQ 自身的架构出发，希望能够以最低的改造成本支持灾备。我们发现客户端都是根据 Namesrv 返回的元数据进行生产、消费，只要客户端能够在机房故障时，可以根据元数据自动将流量切走即可，因此我们将视角移到了客户端，希望从客户端上支持灾备的功能。

RocketMQ 所有 Broker 都会将自己注册到 Namesrv 上去，一旦某个 Broker 组故障，那么它的信息将会被从 Namesrv 中移除，客户端也就无法再向这类 Broker 组发送、拉取消息。基于以上逻辑，只要我们将 Broker组部署在不同机房中，便可以做到机房级别的灾备效果。部署架构如下：

我们以一个实际的例子来讲解以上方案的可行性：Topic-A 在两个可用区上均存在分区，SDK在使用时需要配置自己所在的region。

对于生产者来说，客户端只会向位于相同可用区的分区发送消息。例如：位于可用区1的客户端只会向可用区1发送消息，当可用区1故障时，由于在可用区1不存在可写的分区，便会开始向可用区2发送消息，从而实现生产侧的自动切流。消费者同样需要配置 region ，所有的消费实例会先按照可用区分别去做 rebalance：分区会优先被相同可用区的消费者去分配消费。当可用区1故障时，由于生产者已经将流量切走，因此消费者不需要做特殊变更就做到了消费自动切流。

该方案对于业务来说是一个可选项，业务可自行决定是否需要开启灾备模式，因此较为灵活，可以说是结合了以往两种机房灾备方案的优点，但是仍有不足之处，比如故障集群在故障期间历史消息不可被消费等，后续也会不断的优化方案。

03 来做个总结吧！

本文介绍了四种部署模式，针对不同的业务需求提供不同的部署模式，总结如下：

目前以上方案在小米内部均有具体的业务场景，消息量约占总体的 90%，未来也会逐步将剩余流量相关集群全部升级为机房灾备集群，从而提供 99.99% 的可用性服务能力。