消息队列术语对照要看清什么
消息队列产品线比较分散：同一家既有自研消息服务，也有托管 RocketMQ 与 Kafka，名称相近但语义不同。对照时先确定协议与语义——是 RocketMQ 还是 Kafka 协议、是否要求分区顺序、是否支持事务消息与延时消息、重试与死信策略怎么配。这些比产品名更能决定客户端代码要不要改。
术语对照
| 概念 | 阿里云 | 腾讯云 | 华为云 |
|---|---|---|---|
| RocketMQ 托管 | 云消息队列 RocketMQ 版 | 消息队列 TDMQ（RocketMQ 版） | 分布式消息服务 DMS（RocketMQ 版） |
| 核心对象 | Topic、Group、消息 | Topic、Group、消息 | Topic、Group、消息 |
| 顺序消息 | 支持分区顺序 | 支持分区顺序 | 支持分区顺序 |
| 延时与事务 | 支持延时与事务消息 | 按产品版本支持 | 按产品版本支持 |
| 重试与死信 | 按实例策略与消费位点控制 | 有重试与死信队列配置 | 有重试与死信队列配置 |
| 计费 | 按实例规格或按量 | 按实例规格或按量 | 按实例规格或按量 |
典型使用场景
- 自建 RocketMQ 搬迁到托管服务，评估客户端与协议差异
- 跨厂商消息方案统一：把不同产品的 Topic 命名与权限模型映射成内部规范
- 异步解耦改造：用消息队列替代同步调用，降低系统耦合
- 流量削峰：把突发写入排队化，由消费者按能力消费
- 数据同步：用消息通道把变更事件投递到下游系统
- 容灾切换：评估多可用区部署与消息堆积后的恢复策略
迁移与接入核对项
迁移与接入核对项
# 协议与客户端：确认 Broker 协议与客户端版本，名称相同不代表接口一致
# 命名规范：Topic 与 Group 的字符集与长度限制各家不同，混用会导致订阅失败
# 权限模型：实例级、Topic 级授权粒度不同，迁移后要重新配置访问控制
# 重试策略：最大重试次数与退避方式显式设置，不要依赖默认值
# 死信处理：明确死信队列的告警与人工/自动兜底流程
# 监控口径：堆积量、端到端时延、消费失败率的统计方式与告警阈值逐项对齐MQ 迁移要先核对端到端时延与堆积告警口径：不同产品的默认重试与死信策略不同，业务侧必须显式配置，否则故障消息会静默沉淀。
切换消费者时避免新旧消费者同时订阅同一队列：并发消费会打乱顺序或造成重复处理，除非业务本身幂等且与顺序无关。