云计算之云原生（上）

一、消息队列RocketMQ

[1.1 功能介绍](#1.1 功能介绍)

[1.1.1 业务消息首选：消息队列 RocketMQ](#1.1.1 业务消息首选：消息队列 RocketMQ)

[1.1.2 【收发流量隔离约束】读写分离控制提高集群稳定性](#1.1.2 【收发流量隔离约束】读写分离控制提高集群稳定性)

[1.1.3 【Dashboard 仪表盘】实时观测实例状态](#1.1.3 【Dashboard 仪表盘】实时观测实例状态)

[1.1.4 【消息轨迹追踪】消息生命周期状态一目了然](#1.1.4 【消息轨迹追踪】消息生命周期状态一目了然)

[1.1.5 【实时扩缩容】解决自建消息扩容慢、缩容困难痛点](#1.1.5 【实时扩缩容】解决自建消息扩容慢、缩容困难痛点)

[1.1.6 【稳定性优化】存储碎片整理，优化堆积冷读性能](#1.1.6 【稳定性优化】存储碎片整理，优化堆积冷读性能)

[1.2 最佳实践](#1.2 最佳实践)

[1.2.1 最佳时间 -- 容量规划](#1.2.1 最佳时间 – 容量规划)

[1.2.2 最佳实践 -- 业务规划](#1.2.2 最佳实践 – 业务规划)

[1.2.3 最佳实践 -- 接入规范](#1.2.3 最佳实践 – 接入规范)

[1.2.4 最佳实践 -- 实例 & Topic & Tag 设计](#1.2.4 最佳实践 – 实例 & Topic & Tag 设计)

[1.2.5 最佳实践 -- Topic 和 Group 的使用规范和建议](#1.2.5 最佳实践 – Topic 和 Group 的使用规范和建议)

[1.2.6 最佳实践 -- 订阅关系一致](#1.2.6 最佳实践 – 订阅关系一致)

[1.2.7 最佳实践 -- 消息堆积处理](#1.2.7 最佳实践 – 消息堆积处理)

[1.2.8 最佳实践 -- 生产、消费者创建](#1.2.8 最佳实践 – 生产、消费者创建)

[1.3 常见问题](#1.3 常见问题)

[1.3.1 Apache RocketMQ Admin工具兼容性？](#1.3.1 Apache RocketMQ Admin工具兼容性？)

[1.3.2 Apache RocketMQ Request-Reply消息？](#1.3.2 Apache RocketMQ Request-Reply消息？)

[1.3.3 MQ 是否能保证消息不重复？](#1.3.3 MQ 是否能保证消息不重复？)

[1.3.4 消息队列定时消息一定准时吗？](#1.3.4 消息队列定时消息一定准时吗？)

总结

一、消息队列RocketMQ

1.1 功能介绍

1.1.1 业务消息首选：消息队列 RocketMQ

RocketMQ 诞生于阿里内部核心电商系统，主要为业务系统提供异步化、低延迟、业务解耦、削峰填谷、异构数据复制的能力。核心价值主打：稳定可靠，功能丰富，可观测易运维，弹性扩展，方便易用，轻量集成帮助业务系统完成高价值数据传输和驱动。

功能丰富、开箱即用

多类型消息：顺序、定时、事务等多类型消息
多消费模式：集群、广播多消费模式、SQL/TAG多类型过滤

高性能、低延迟首选

高性能：横向可扩展，高并发海量存储支持
低延迟：存储毛刺优化，高峰期顺滑写入

可观测、易运维

可观测：轨迹追踪、告警大盘，可查可监控
易运维：消息路由、消息重置，消息可运维管理

业内领先SLA

跨可用区秒级RTO：可用性最高 99.99%
多副本：数据可靠性99.9999999%

1.1.2 【收发流量隔离约束】读写分离控制提高集群稳定性

读写TPS自定义比例量化隔离约束，以明确SLA确保收发相互不影响，提高集群稳定性

场景痛点：

**消息收发缺少量化SLA：**自建集群以机器规格评估水位，对收发消息TPS缺少量化SLA保障，特殊场景下容易造成短板和风险。
**读写压力不隔离存在风险：**消息场景存在堆积和冷读，一对一和一堆多广播；大量广播和冷读场景容易影响热消息写入，造成故障。需要对读写进行隔离和限制。

产品能力价值：

**消息收发量化SLA保障：**阿里云消息实例全部提供TPS量化SLA保障，涵盖各种极端场景，业务评估更容易。
**读写自定义比例隔离和约束：**消息收发全部独立限流，可以保证大量冷读和广播场景被限制，避免影响热消息写入。

1.1.3 【Dashboard 仪表盘】实时观测实例状态

实例 Top10 问题资源：一眼可见

**按失败率倒序排序：**着重加强了复杂的消费链路的指标和监控
**按堆积严重程度排序：**快速找到异常 Topic 并介入处理
**按消息量倒序排序：**为用户提供最佳模板，并持续迭代更新

生产消费指标详情：定位问题边界和原因

**消息量指标：**着重加强了复杂的消费链路的指标和监控
**堆积量指标：**消息量和延时时间，准确反映消费及时性
**错误率指标：**反映生产和消费的健康度
**耗时指标：**为用户提供最佳模板，并持续迭代更新

实例使用量指标：容量成本规划

**流量峰值：**评估容量规格，及时扩缩容
**限流次数：**评估容量规格，及时扩缩容
**存储、带宽使用量：**评估使用量

1.1.4 【消息轨迹追踪】消息生命周期状态一目了然

**便捷的查询能力：**可根据消息基本信息查询相关的轨迹；还可以根据结果状态、耗时时长来过滤查询，过滤出有效轨迹快速定位问题。
**详细的tracing信息：**除了各个生命周期的时间和耗时数据，还包含了生产者、消费者的账号和机器信息。
**优化展示效果：**不同的消息类型轨迹；多个消费 GroupID 的场景；同个消费 GroupID 多次重投的场景等。

1.1.5 【实时扩缩容】解决自建消息扩容慢、缩容困难痛点

消息系统容量保障是核心链路生命线，容量过剩是浪费，容量不足系统挂掉，扩缩容效率和稳定性至关重要。

自建消息扩缩容痛点

痛点一：扩容效率低，无法应对突发流量和故障应急

缺少弹性资源池，物理资源生产慢，故障应急恢复慢
部署自动化、标准化扩缩容系统欠缺，手工脚本易错高风险

痛点二：缩容需要缩队列，平滑下线难，容易造成故障

缩容需要对队列做长时间禁写等待消息消费完，否则丢消息
队列禁写缩容期间容易造成消费空转和不均衡

痛点三：扩缩容受本地磁盘挂载架构约束，利用率低

挂载本地磁盘的架构，流量不足或者磁盘不足时只能一起扩容，存在浪费
挂载本地磁盘，无法缩容，磁盘太小消息保存不够，容量太大后期磁盘无法缩

阿里云云消息扩缩容能力

能力一：全系列实例随时升降配，最快秒级生效

云产品拥有大量弹性资源池，热备资源实时扩容
全自动运维系统，扩缩容过程无需人工介入，不易出错

能力二：扩缩容业务无感，无需业务配合

云上存算分离架构，队列变化客户端侧无感知，无均衡性和丢消息问题

能力三：存算分离+分级存储能力，计算和存储按需扩缩

云上消息收发按需扩容即可，和存储解耦
分级存储能力，支持存储低成本按量使用，不再有任何浪费，费用降低67%。

1.1.6 【稳定性优化】存储碎片整理，优化堆积冷读性能

消息读取场景堆积不可避免，大量堆积冷读情况下的性能会影响热消息写入，需要做好隔离和优化。

热数据预计算索引：消息写入时预计算本分区的偏移量，不影响实时消息写入
异步归并索引计算：异步启动归并索引计算流程，以最小代价完成索引更新，不影响实时消息读取
消息存储碎片规整和替换：消息原始碎片化数据合并，顺序写入磁盘，最小限度影响 IO 性能

**应用场景：**实时计算场景大规模Scan、堆积消费场景性能优化

**客户痛点：**在大规模消息堆积或者实时计算场景下存储碎片化会导致冷读性能差、延迟高。

**核心价值：**通过碎片规整充分利用操作系统预读提高性能和体验。

1.2 最佳实践

1.2.1 最佳时间 -- 容量规划

问题一：怎样评估实例容量：

实例详情页》查看指定实例数据统计，可以看到所选时间段内的最大消息收发的TPS峰值。
铂金版实例可以根据这个数据来添加报警监控和判断业务。

问题二：怎样查看标准版实例的消耗

可以查看概览总消息量模块

问题三：有哪些已下线，需要清理资源？

指定一段时间内（例如近一周），按Topic的消息发送量由小到大排序，查看是否有消息发送量为0的Topic，这些Topic相关的业务或许已下线。
指定一段时间内（例如近一周），按GroupID的消息消费量由小到大排序，查看是否有消息消费量为0的GroupID，这些GroupID相关的业务或许已下线。

1.2.2 最佳实践 -- 业务规划

问题一：业务峰值分布情况？

查看 Topic 消息接收量的每天的高峰时间段
查看 Topic 消息接收量周末和非周某的消息量差别
查看 Topic 消息接收量节假日的变化情况

问题二：目前哪些业务在上升趋势？

查看消息量辅助判断业务量变化趋势

问题三：怎样优高消费者系统性能

查看消息处理耗时，是否在合理范围内，有提升的空间。

1.2.3 最佳实践 -- 接入规范

资源管理：严格管理 Topic、Group 资源创建删除等操作。

合理申请 Topic、Group资源：基于业务域合理拆分 Topic、Group，避免大量创建 Topic 、Group。
严格控制元数据操作频率：务必关闭自动创建资源开关，严格限制管控接口写操作频率，避免数据节点压力。
历史无效资源及时清理：历史无效 Topic、Group 及时清理，避免元数据膨胀。

容量管理：业务接入时合理评估容量和业务优先级

业务隔离拆分：基于业务重要性差异和业务容量诉求，拆分不同物理集群，避免大集群运维。
资源 Buffer 管理：相同可用区维持有效 buffer 水位，避免紧急扩容困难。

1.2.4 最佳实践 -- 实例 & Topic & Tag 设计

实例拆分原则

按业务运行环境隔离：日常、预发、线上环境各自使用不同的实例隔离。
按业务重要程度隔离：对于稳定性 SLA 要求不一样的业务，使用不同的实例隔离。

Topic & Tag 拆分原则

消息类型是否一致：如普通消息，事务消息，定时消息，顺序消息，不同的消息类型使用不同的 Topic，无法通过 Tag 进行区分。
业务是否相关联：没有直接关联的消息，如淘宝交易消息，京东物流消息使用不同的 Topic 进行区分；而同样是天猫交易消息，电器类订单、女装类订单、化妆品类订单的消息可以用 Tag 进行区分。
消息优先级是否一致：如同样是物流消息，盒马必须小时内送达，天猫超市 24 小时内送达，淘宝物流则相对会会慢一些，不同优先级的消息用不同的 Topic 进行区分。
消息量级是否相当：有些业务消息虽然量小但是实时性要求高，如果跟某些万亿量级的消息使用同一个 Topic，则有可能会因为过长的等待时间而『饿死』，此时需要将不同量级的消息进行拆分，使用不同的 Topic。

1.2.5 最佳实践 -- Topic 和 Group 的使用规范和建议

Topic 使用规范

**消息类型规范：**按照业务实际需求设置消息类型，普通、事务、定时、全局顺序、分区顺序按照类型选择使。

影响：

场景1 扩缩容、标准版铂金版互转：无法根据消息类型正确处理中间状态的消息，例如未提交的事务消息、定时中的消息、顺序消息乱序等。

场景2 排查问题：消息类型不同，排查的业务流程会错误或忽略一些关键检查点；快速恢复手段也会因为消息类型而判断失误，引起二次问题。

场景3 可观测：根据消息类型展示不同消息生命周期，统计相关的报表。

Group 使用规范

**Group消费模式统一：**同个消费Group只能有一种消费模式，不能部分机器节点是集群消费，部分机器节点是广播消费。

**影响：**导致消费位点提交混乱，消息丢失。

**不相关的业务处理使用不同的Group：**一个Group可以订阅消费多个Topic的消息，但这些消息是相关的业务处理逻辑。不同的业务使用不同的Group订阅消费。

**影响：**随着业务增长，当系统需要架构优化或业务系统拆分时，使用同个Group消费的会需要付出额外的代价才能达到平滑无损迁移的效果。

1.2.6 最佳实践 -- 订阅关系一致

同一个 Consumer ID 下所有 Consumer 实例的处理逻辑必须完全一致

MQ 里的一个 Consumer ID 代表一个 Consumer 实例群组，一个 Consumer ID 下的多个 Consumer 实例的订阅关系需要一致。

MQ 的订阅关系一致性：一致

同一个 Consumer ID 下所有的实例需在以下两方面均保持一致：

订阅的 Topic 必须一致；
订阅的 Topic 中的 Tag 必须一致

请区分订阅关系一致的概念和一个 Consumer ID 可以订阅多个 Topic 的概念

用户可以用一个 Consumer ID 订阅多个 Topic，只要在同一个实例里订阅就可以，但是当这个 Consumer ID 需要部署多个实例时，请确保多实例的订阅关系一定要保持一致。

针对消费逻辑做消息幂等

无论是消息粒度负载均衡策略还是队列粒度负载均衡策略，在消费者上线或下线、服务端扩缩容等场景下，都会触发短暂的重新负载均衡动作。此时可能会存在短暂的负载不一致情况，出现少量消息重复的现象。因此，需要在下游消费逻辑中做好消息幂等去重处理。

1.2.7 最佳实践 -- 消息堆积处理

消息消费原理（两阶段）

阶段一：后台线程长轮询批量拉取消息

阶段二：本地多线程提交 消费任务，队列缓冲满自动流控

优化原则

原则一：控制消费逻辑复杂度，确保消费耗时符合预期

原则二：当且仅当消费耗时合理但吞吐不足的情况下，适当提高并发度

理想并发度：节点数 * 核数 *（计算耗时+IO 耗时）/计算耗时

|-----------|------------------|
| 普通消息最大并发度 | 理想并发度 |
| 顺序消息最大并发度 | Min(消息分区数，理想并发度) |

最佳实践

1、堆积报警监控

RocketMQ 控制台报警监控
应用监控

2、确认消息是否堆积在本地

排查应用本地拉消息限流日志

3、确认消费耗时是否合理

消费者状态查询
消息轨迹查询
应用堆栈排查

4、扩容或者逻辑修正

下游逻辑排查梳理
适当提高消费并发度，扩容节点

5、堆积消除

堆积下降，告警解除

1.2.8 最佳实践 -- 生产、消费者创建

不建议单一进程创建大量生产者

云消息队列 RocketMQ 版的生产者和主题是多对多的关系，支持同一个生产者向多个主题发送消息。对于生产者的创建和初始化，建议遵循够用即可、最大化复用原则，如果有需要发送消息到多个主题的场景，无需为每个主题都创建一个生产者。

不建议在单一进程内创建大量消费者

云消息队列 RocketMQ 版的消费者在通信协议层面支持非阻塞传输模式，网络通信效率较高，并且支持多线程并发访问。因此，大部分场景下，单一进程内同一个消费分组只需要初始化唯一的一个消费者即可，开发过程中应避免以相同的配置初始化多个消费者。

不建议频繁创建和销毁生产、消费者

云消息队列 RocketMQ 版的生产、消费者是可以重复利用的底层资源，类似数据库的连接池。因此不需要在每次接收消息时动态创建生产、消费者，且在消费完成后销毁生产、消费者。这样频繁地创建销毁会在服务端产生大量短连接请求，严重影响系统性能。

1.3 常见问题

1.3.1 Apache RocketMQ Admin工具兼容性？

消息队列RocketMQ版暂不支持使用Apache RocketMQ的Admin API以及CLI管理实例、Topic和Group资源。

1.3.2 Apache RocketMQ Request-Reply消息？

暂不支持。

1.3.3 MQ 是否能保证消息不重复？

绝大多数情况下，消息是不重复的。作为一款分布式消息中间件，在网络抖动、应用处理超时等异常情况下，无法保证消息不重复，但是能保证消息不丢失。

1.3.4 消息队列定时消息一定准时吗？

定时消息是指在指定时间（STARTDELIVERTIME）后才可被消费者消费，如果当前有消息堆积，那么这条定时消息会排在堆积消息后面，所以，消息堆积时，定时消息不一定准时。

总结

1、RocketMQ是一款源自阿里巴巴内部的核心电商系统，在提供稳定可靠的消息传递服务，支持异步化、低延迟、业务解耦等功能。它提供了多种类型的消息（如顺序、定时、事务消息）和消费模式（如集群、广播模式），并具备高性能、低延迟的特点。

2、RocketMQ还强调了可观测性和易运维性，通过消息轨迹追踪和实时仪表盘监控，帮助用户快速定位和解决问题。

3、RocketMQ支持实时扩缩容，优化了存储碎片问题，提升了冷读性能，并提供了一系列的最佳实践指南，帮助用户合理规划和管理消息队列资源，确保系统的稳定性和高效运行。