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% 的可用性服务能力。