最新要闻

广告

手机

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

iphone11大小尺寸是多少?苹果iPhone11和iPhone13的区别是什么?

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

警方通报辅警执法直播中被撞飞:犯罪嫌疑人已投案

家电

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

关键词: