基于消息队列 RocketMQ 的大型分布式应用上云最佳实践

基于消息队列 RocketMQ 的大型分布式应用上云最佳实践

作者｜绍舒审核&校对：岁月、佳佳编辑&排版：雯燕

前言

消息队列是分布式互联网架构的重要基础设施，在以下场景都有着重要的应用：

应用解耦 削峰填谷 异步通知 分布式事务 大数据处理

核心能力

商业版本消息队列 RocketMQ 相比较开源版本 RocketMQ 和其他竞品，主要有以下几点优势。

开箱即用、功能丰富 高性能、无限扩展能力 可观测、免运维能力 高 SLA 和稳定性保证

开箱即用、功能丰富

消息队列 RocketMQ 提供了定时、事务、顺序等多类型消息的支持，且支持广播、集群两种消费模式；另外在协议层面，提供 TCP/HTTP 多协议支持，还提供了 TAG/SQL 属性过滤功能，极大程度地拓宽了用户的使用场景。

高性能、无限拓展能力

消息队列 RocketMQ 经受了阿里核心电商历年双十一洪峰的考验，支持千万级 TPS 消息收发和亿级消息堆积的能力，并且能够为消息提供毫秒级端到端延迟保障，另外还提供分级存储，支持海量消息的任意保存时间。

可观测、免运维能力

消息队列 RocketMQ 提供了一个可观测性大盘，支持细粒度数据大盘，提供了消息全链路生命周期追踪和查询能力，对各个指标提供了相应的监控报警功能；此外，还提供了消息回溯和死信队列功能，能够保证用户的消息能够随时回溯消费。

高 SLA 和稳定性保障

消息队列 RocketMQ 的稳定性是我们一贯、持续、稳定投入的重要领域，提供了高可用部署和多副本写入功能；另外也支持同城多 AZ 容灾和异地多活。

产品剖面

接下来，我们会从以上的产品核心能力中挑选几个剖面，并且结合具体的场景和实践来做进一步的介绍。

多消息类型支持

高可用顺序消息

商业版本消息队列 RocketMQ 使用的顺序消息我们称之为高可用顺序消息。在介绍高可用顺序消息之前，首先简要介绍下开源版本 RocketMQ 的顺序消息。 顺序消息分为两种类型，全局顺序消息和分区顺序消息。

全局顺序消息：在 RocketMQ 存储层只会分配一个分区，也就是说全局顺序 Topic 的可用性跟单一副本的可用性强相关，且不具备可扩展的能力。 分区顺序消息：所有消息根据 Sharding Key 进行分区。同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。Sharding Key 是顺序消息中用来区分不同分区的关键字段。

一个逻辑顺序分区（PartitionGroup）下有多个物理分区。 其中任意一个物理分区是可写的，那么整个逻辑分区是可写且有序的。 我们基于 happened-before 的原则设计了一套基于分区位点的排序算法。 根据该算法，消费者在消费某一逻辑分区时，会从其所属的各个物理分区中拉取消息并进行合并排序，得出正确的消息顺序流。

可用性问题：高可用顺序消息将具备与普通消息一致的可用性，在某副本不可用时，可快速重试至其它副本。 可扩展性问题：普通顺序消息，特别是普通全局顺序消息，不具备良好的扩展能力，只能固定在特定的副本中。高可用顺序消息的逻辑顺序分区可以将物理顺序分区分散在多个副本中。 热点问题：普通顺序消息根据 Key 将一类消息 Hash 至同一个分区中，热点 Key 会导致热点分区，高可用顺序消息具备横向扩展能力，可以为逻辑顺序分区添加多个物理分区来消除热点问题。 单点问题：普通全局顺序消息，仅包含单分区，极易出现单点故障，高可用顺序消息可以消除全局顺序消息的单点问题。

尤其需要注意的是热点问题，在阿里巴巴内部某电商业务大促时，因发送到顺序 Topic 的某一特定的 ShardingKey 数量过多，集群中一个副本接收到了大量该 ShardingKey 的消息，导致该副本超出其负荷上限，造成了消息的延迟和堆积，一定程度上影响了业务。在使用了高可用顺序消息之后，由于其在多物理分区中的负载均衡特性，提升了集群顺序消息的承载能力，从而避免了热点问题的出现。

秒级精准定时消息

任意定时时间 超长定时时间 海量定时消息 删除定时消息 高可用 高性能

分布式事务消息

发送方将半事务消息发送至消息队列 RocketMQ 版服务端。 消息队列 RocketMQ 版服务端将消息持久化成功之后，向发送方返回 Ack 确认消息已经发送成功，此时消息为半事务消息。 发送方开始执行本地事务逻辑。 发送方根据本地事务执行结果向服务端提交二次确认（Commit 或是 Rollback），服务端收到 Commit 状态则将半事务消息标记为可投递，订阅方最终将收到该消息；服务端收到 Rollback 状态则删除半事务消息，订阅方将不会接受该消息。

分级存储

背景

随着云上客户的不断增多，存储逐渐成为 RocketMQ 运维的重要瓶颈，这包括并且不限于：

内存大小有限，服务端不能将所有用户的数据全部缓存在内存中；在多租户场景下，当有用户拉取冷数据时，会对磁盘造成较大 IO 压力，从而影响共享集群的其他用户，亟需做到数据的冷热分离。 云上有单租户定制化消息存储时长的需求。而 RocketMQ Broker 中所有用户的消息是放在一个连续文件中进行存储的，无法针对任何单一用户定制存储时长，即现有的存储结构无法满足这样的需求。 如果能对海量数据提供更低成本的存储方式，可以大幅降低云上 RocketMQ 的磁盘存储成本。

基于以上现状，分级存储方案应运而生。

架构

分级存储的整体架构如下：

connector 节点负责将 broker 上的消息实时同步到 OSS 上 historyNode 节点将用户对冷数据的拉取请求转发至 OSS 上 在 OSS 中是按照 Queue 粒度来组织文件结构的，即每个 Queue 会由独立的文件进行存储，从而保证了我们可以针对于租户定义消息的存储时长。

使用场景

基于分级存储，我们进一步拓展了用户的使用场景：

自定义存储时间：在消息数据的冷热分离之后，我们将冷数据存储到 OSS 这样的存储系统中，能够实现用户自定义的存储时间。 消息审计：在消息的存储之间从数天扩展到自定义后，消息的属性从一个临时性的中转数据变成了用户的数据资产，而消息系统也从数据中枢转变成了数据仓库；用户能够基于数据仓库实现更多样的审计、分析、处理功能。 消息回放：在流计算场景中，消息回放是非常重要的一个场景；通过拓展消息的存储时间之后，流计算能够实现更加丰富的计算分析场景。

稳定性

消息队列 RocketMQ 的稳定性是我们一贯、持续、稳定投入的重要领域。在介绍我们在稳定性的最新工作之前，首先带大家回顾下 RocketMQ 高可用架构的演进路线。

高可用架构演进路线

第一代主备架构只起到了冷备的作用，且主备切换需要人工介入，在大规模场景下有较大的资源浪费以及运维成本。 第二代架构引入了 Zookeeper 和 Controller 节点，架构上更加复杂，在主备切换做到了自动化，但故障转移时间较长，一般是 10 秒左右完成选主。 第三代 Raft 架构目前暂未在云上和阿里集团内大规模应用，且 Raft 协议就决定了需要选主，新主还需要被客户端路由发现，整个故障转移时间依然较长；另外，强一致的 Raft 版本并未支持灵活的降级策略，无法在可用性和可靠性之间做灵活的权衡。

为了应对云上日益增长的业务规模、更严苛的 SLA 要求、复杂多变的专有云部署环境，当前的消息系统需要一种架构简单、运维简单、有基于当前架构落地路径的方案，我们将其称作秒级 RTO 多副本架构。

新一代秒级 RTO 多副本架构

秒级 RTO 多副本架构是消息中间件团队设计实现的新一代高可用架构，包含副本组成机制、Failover 机制、对现有组件的侵入性修改等。 整个副本组有以下特点：

Strong Leader/No Election：Leader 在部署时确定，整个生命周期内不会发生切换，但可在故障时被替换。 仅 Leader 支持消息写入：每一个副本组仅 Leader 接受消息写入，Leader 不可用时，整个副本组不可写入。 所有的副本支持消息读取：虽然 Leader 上拥有全量的消息，Follower 上的消息量不对等，但所有的副本都支持消息的读取。 灵活的副本组数量：可以基于可靠性、可用性和成本自由选择副本组的数量。 灵活的 Quorum 数量：最终所有的消息都会同步到整个副本组上，但副本组内可以灵活配置写成功最小副本数。例如 2-3 模式，3 副本情况下，2 副本成功即为写成功。同时，在副本不可用的情况下，Quorum 数量也可以动态自行降级。

Producer 在主不可用时，灵活快速地切换至另一个副本组。 Consumer 在某个副本不可用时可快速切换至同副本组另一个副本上进行消息消费。

可观测性

健康大盘

消息链路追踪

应用场景

客户痛点：业务出现消费堆积的用户需要根据消息轨迹抽样数据，综合分析后才能大致判断引起问题原因，排查困难。 核心价值：提高线上运行问题排查的效率，和问题定位的准确性。直接在健康大盘上快速发现风险最高的 Topic 和 Group，并根据各个指标的变化情况快速定位原因。例如消息处理时间过长可以扩容消费者机器或优化消费业务逻辑，如果是失败率过高可以快速查看日志排除错误原因。

事件驱动

大家一定非常熟悉 Gartner，在2018年的一个评估报告里，Gartner 将 Event-Driven Model，列为了未来10大战略技术趋势之一，并且，做出了两个预测：

2022年，超过 60% 的新型数字化商业解决方案，都会采用事件通知的软件模型。 2022年，超过 50% 的商业组织，将会参与到EDA生态系统当中去。

同一年，CNCF 基金会也提出了 CloudEvents，意在规范不同云服务之间的事件通讯协议标准。到目前为止，CloudEvents也已经发布了多个消息中间件的绑定规范。 可见事件驱动是未来业务系统的一个重要趋势，而消息天然具备和事件的亲近性，因此消息队列 RocketMQ，是坚决拥抱事件驱动的。 谈到消息和事件，这里做一个简单的阐述：消息和事件是两种不同形态的抽象，也意味着满足不同的场景：

消息：消息是比事件更通用的抽象，常用于微服务调用之间的异步解耦，微服务调用之间往往需要等到服务能力不对等时才会去通过消息对服务调用进行异步化改造；消息的内容往往绑定了较强的业务属性，消息的发送方对消息处理逻辑是有明确的预期的。 事件：事件相对于消息更加具像化，代表了事情的发送、条件和状态的变化；事件源来自不同的组织和环境，所以事件总线天然需要跨组织；事件源对事件将被如何响应没有任何预期的，所以采用事件的应用架构是更彻底的解耦，采用事件的应用架构将更加具备可扩展性和灵活性。

创建消息队列 RocketMQ 主题

创建目标服务

我们基于容器服务快速创建一个事件驱动的服务，计算负载 Deployment 的 yaml 如下，该服务能够响应事件并将结果打印到标准输出中。

apiVersion: apps/v1 # for versions before 1.8.0 use apps/v1beta1 kind: Deployment metadata: name: eventbridge-http-target-deployment labels: app: eventbridge-http-target spec: replicas: 2 selector: matchLabels: app: eventbridge-http-target template: metadata: labels: app: eventbridge-http-target spec: containers: - name: eb-http-target # 下述镜像暴露了一个 HTTP 地址(/cloudevents)用于接收 CloudEvents，源码参考：https://github.com/aliyuneventbridge/simple-http-target image: registry.cn-hangzhou.aliyuncs.com/eventbridge-public/simple-http-target:latest ports: - containerPort: 8080

创建事件总线 EventBridge 自定义总线

创建事件总线 EventBridge 自定义总线规则

创建事件总线 EventBridge 事件源

发送 RocketMQ 消息

总结

我们选取了消息队列 RocketMQ 的几个产品剖面，从多消息类型、分级存储到稳定性、可观测性，再到面向未来的事件驱动，并结合与开源 RocketMQ 的对比，及具体应用场景的分析，为大家展示了基于消息队列 RocketMQ 的大型分布式应用上云最佳实践。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。