关于阿里云:RocketMQ-在小米的多场景灾备实践案例

0次阅读

共计 3690 个字符，预计需要花费 10 分钟才能阅读完成。

作者：邓志文、王帆

在小米外部，咱们应用 RocketMQ 来为各种在线业务提供音讯队列服务，比方商城订单、短信告诉甚至用来收集 IoT 设施的上报数据，能够说 RocketMQ 的可用性就是这些在线服务的生命线。作为软件开发者，咱们通常心愿服务能够依照现实状态去运行：在没有 Bug 的前提下，零碎能够提供失常的服务能力。

但事实的运维教训通知咱们这是不可能的，硬件故障是十分常见的问题，比方内存故障、磁盘故障等，甚至是机房相干的故障（专线故障、机房拉闸等）。因而咱们须要对数据进行备份，应用多正本的形式来保障服务的高可用。Apache RocketMQ 设计上就反对多正本、多节点容灾，比方 Master-Slave 架构、DLedger 部署模式。

在小米外部，因为是面向在线业务，服务的复原速度至关重要，而基于 Raft 协定的 DLedger 模式能够实现秒级 RTO，因而咱们在 2020 年初选用了 DLedger 架构作为根本的部署模式（在 5.0 中，主从模式也能够做到主动 failover）。反对机房灾备须要减少额定的老本，上面我将用三个灾备部署的实际案例，解说小米如何在老本和可用性的取舍下来反对灾备。

理论在应用中，有许多业务是不须要机房级别容灾的，只有可能做到单机房高可用即可。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 是一种很好的部署思维：主从节点对等部署进而充分利用所有的机器。 咱们尝试间接应用该计划，但遇到了一些问题：

Container 实质上是一个过程。不论其内运行了多少个 Broker，咱们只有对其进行重启操作，都会影响该 Container 外部 Broker 相干的所有 Broker 组，降级时会产生较为重大的影响；
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 的原生能力
主动选主，业务接入不便，无需业务手动切换流量

▷毛病

跨机房部署，容易受网络稳定，集群抖动概率较大
跨机房部署，会减少写入延时，从而升高集群吞吐能力

▷生产耗时

目前看来 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 故障时，因为生产者曾经将流量切走，因而消费者不须要做非凡变更就做到了生产主动切流。

该计划对于业务来说是一个可选项，业务可自行决定是否须要开启灾备模式，因而较为灵便，能够说是联合了以往两种机房灾备计划的长处，然而仍有不足之处，比方故障集群在故障期间历史音讯不可被生产等，后续也会一直的优化计划。

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

目前以上计划在小米外部均有具体的业务场景，音讯量约占总体的 90%，将来也会逐渐将残余流量相干集群全副降级为机房灾备集群，从而提供 99.99% 的可用性服务能力。

正文完