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

在小米内部，我们使用 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