很多团队使用 MQ 时，代码只是一部分，真正容易踩坑的是 topic 申请、配置生效、消费者绑定、重试策略和死信队列。
这篇整理一份 MQ Topic 实践清单。
Topic 不是随手创建的字符串
在正式环境里，topic 往往需要申请、审批和绑定生产者、消费者。不要把 topic 当成代码里随手写的常量。
上线前要确认：
- topic 是否已经创建。
- 生产者是否有发送权限。
- 消费者是否有订阅权限。
- 预发和生产是否分别配置。
- 配置中心里的 topic 名是否和代码一致。
很多“消费者没有消息”的问题，最后都不是代码问题，而是配置或权限问题。
配置中心要和代码一起看
MQ 配置经常不在本地配置文件里，而在配置中心或部署平台里。排查时要同时看：
- 代码里的监听器。
- 配置中心里的 topic。
- 部署环境实际读取的配置。
- 生产者发送时使用的 topic。
如果本地配置很旧，不能只根据本地 YAML 判断线上行为。
消费者异常要明确抛给 MQ
消费逻辑里常见两种处理方式：
- 异常直接抛出，让 MQ 触发重试。
- 业务自己捕获异常，写失败表或失败日志。
这两种都可以，但不要混着来。如果异常被吞掉，MQ 可能认为消费成功，消息就不会再重试。
更稳的做法是明确约定：
- 哪些异常可以重试。
- 哪些异常直接进入失败记录。
- 重试次数在哪里配置。
- 超过重试次数后是否进死信队列。
bizId 和幂等要提前想
消息消费通常要考虑重复投递。上游如果能提供稳定的业务 ID，可以用它做幂等键。
幂等设计可以放在：
- 消费记录表。
- Redis 去重 key。
- 业务唯一索引。
- 下游写入前的状态检查。
没有幂等的 MQ 消费，很容易在重试、超时或消费者重启时产生重复数据。
死信队列不是摆设
死信队列适合承接多次重试仍失败的消息。上线前要确认：
- 当前 MQ 版本是否支持死信队列。
- 死信队列在哪里查看。
- 是否需要手动重放。
- 重放时是否会产生重复业务影响。
如果平台只提供页面操作，也要把操作入口和权限提前确认好。
Topic 拆分要可维护
把一个大 topic 拆成多个业务 topic，可以降低单个消费者复杂度。但 topic 太多会带来配置成本。
拆分时可以按这些维度判断：
- 业务类型是否不同。
- 消费速率是否不同。
- 失败影响是否需要隔离。
- 是否需要独立扩容。
- 是否有独立监控需求。
MQ 的好设计不是 topic 越细越好，而是让消息流和业务边界对齐。
实践清单
上线前可以按这个顺序核对：
- topic 已创建。
- 生产者和消费者权限已绑定。
- 配置中心已发布。
- 消费者监听器已生效。
- 异常处理策略明确。
- 重试次数可确认。
- 死信队列可查看。
- 幂等键可追踪。
- 日志能定位消息 ID 和业务 ID。
MQ 的稳定性不只在代码里，也在配置、权限和运维入口里。把这些前置核对清楚，线上排查会轻很多。
正文完
