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

简介: 小米内部使用 RocketMQ 来为各种在线业务提供消息队列服务,比如商城订单、短信通知等,可以说 RocketMQ 的可用性就是这些在线服务的生命线。Apache RocketMQ 支持多副本、多节点容灾,比如 Master-Slave 架构、DLedger 部署模式。一起来了解小米如何在成本和可用性的取舍上支持灾备,保证服务的高可用吧~

图片

本文作者:邓志文、王帆

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来做个总结吧!

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

image.png

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

图片

相关实践学习
RocketMQ一站式入门使用
从源码编译、部署broker、部署namesrv,使用java客户端首发消息等一站式入门RocketMQ。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
相关文章
|
1月前
|
消息中间件 存储 数据库
RocketMQ 流存储解析:面向流场景的关键特性与典型案例
RocketMQ 流存储解析:面向流场景的关键特性与典型案例
88429 0
|
4天前
|
消息中间件 数据可视化 Go
Rabbitmq 搭建使用案例 [附源码]
Rabbitmq 搭建使用案例 [附源码]
16 0
|
9天前
|
消息中间件 Serverless Windows
消息队列 MQ产品使用合集之MQTT协议是否可以应用于社交软件的系统通知场景
阿里云消息队列MQ(Message Queue)是一种高可用、高性能的消息中间件服务,它允许您在分布式应用的不同组件之间异步传递消息,从而实现系统解耦、流量削峰填谷以及提高系统的可扩展性和灵活性。以下是使用阿里云消息队列MQ产品的关键点和最佳实践合集。
|
1月前
|
消息中间件 监控 负载均衡
RocketMQ实践问题收集
RocketMQ实践问题收集
|
1月前
|
消息中间件 JSON Java
RabbitMQ入门指南(六):消息转换器及其案例
RabbitMQ是一个高效、可靠的开源消息队列系统,广泛用于软件开发、数据传输、微服务等领域。本文主要介绍了RabbitMQ默认转换器、JSON转换器及其案例等内容。
61 0
|
1月前
|
消息中间件 微服务
RabbitMQ入门指南(四):交换机与案例解析
RabbitMQ是一个高效、可靠的开源消息队列系统,广泛用于软件开发、数据传输、微服务等领域。本文主要介绍了交换机在RabbitMQ中的作用与类型、交换机案例(Fanout交换机、Direct交换机、Topic交换机)等内容。
130 0
|
1月前
|
消息中间件 存储 中间件
【SpringCloud Stream消息驱动、设计思想以及整合rabbitmq消息队列案例--学习笔记】
【SpringCloud Stream消息驱动、设计思想以及整合rabbitmq消息队列案例--学习笔记】
89 0
|
1月前
|
消息中间件 存储 数据库
深度剖析 RocketMQ 5.0,流存储:流场景的诉求是什么?
本文将从使用的角度出发,来更详细的展示一下流存储的场景,看看它和业务消息的场景有哪些区别。 RocketMQ 5.0 面向流存储的场景,提供了哪些特性。再结合两个数据集成的案例,来帮助大家了解流存储的用法。
3405 2
|
1月前
|
消息中间件 SQL 容灾
深度剖析 RocketMQ 5.0,消息进阶:如何支撑复杂业务消息场景?
本文主要学习 RocketMQ 的一致性特性,一致性对于交易、金融都是刚需。从大规模复杂业务出发,学习 RocketMQ 的 SQL 订阅、定时消息等特性。再从高可用的角度来看,这里更多的是大型公司对于高阶可用性的要求,如同城容灾、异地多活等。
108246 287
|
1月前
|
消息中间件 Cloud Native 物联网
深度剖析 RocketMQ 5.0,消息基础:RocketMQ 在业务消息场景的基础优势是什么?
本文主要介绍业务消息的应用解耦场景,具体解耦什么? RocketMQ 在业务消息场景的基础特性。业界那么多消息队列能实现应用解耦,RocketMQ 在基础特性上有哪些增强?
125353 2
深度剖析 RocketMQ 5.0,消息基础:RocketMQ 在业务消息场景的基础优势是什么?