云计算之云原生（上）

一、消息队列RocketMQ

1.1 功能介绍

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

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

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

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

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

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

1.2 最佳实践

1.2.1 最佳时间 – 容量规划

1.2.2 最佳实践 – 业务规划

1.2.3 最佳实践 – 接入规范

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

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

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

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

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

1.3 常见问题

1.3.1 Apache RocketMQ Admin工具兼容性？

1.3.2 Apache RocketMQ Request-Reply消息？

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

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。