RocketMQ 面向业务消息提供普通、FIFO、延迟和事务等消息类型。先按失败语义选择类型，再选择 Java 客户端 API；不要把所有 Topic 都配置成最强语义，因为顺序和事务会增加约束与成本。
Table of contents
Open Table of contents
核心模型
Topic 是同类业务消息的逻辑容器，MessageQueue 是存储与传输的最小队列单元，ConsumerGroup 表示共同分担消息的一组消费者。生产者发送成功后，消费者仍可能因为超时或故障收到重复消息。
| 类型 | 适合 | 必须定义的边界 |
|---|---|---|
| NORMAL | 一般异步事件 | 重试与幂等 |
| FIFO | 同一业务组有先后关系 | MessageGroup、阻塞策略 |
| DELAY | 到指定时间后可消费 | 时间精度、最大延迟、取消方式 |
| TRANSACTION | 本地事务与消息发送协同 | 事务检查、未知状态、幂等 |
RocketMQ 5.0 概念文档说明 Topic 会关联消息类型。创建资源时应让声明与发送行为一致。
顺序和延迟都不是全局魔法
FIFO 顺序通常限定在同一个 MessageGroup，例如 orderId。不同订单可以并行，同一订单串行。运行实验室分区测试理解稳定业务键：
mvn -Dtest=DistributedMechanismsTest#equalMessageKeysStayInOnePartition test延迟消息适合订单超时检查、稍后通知等任务，但消费时仍要重新读取当前业务状态，因为订单可能已经支付或取消。高精度定时、大规模可取消任务需要额外评估定时系统或持久工作流。
事务消息通常经历半消息、本地事务、提交/回滚和 Broker 回查。回查方法可能执行多次，必须只读取确定的本地事务状态，不能再次产生扣款副作用。
Java 客户端验收
固定客户端与服务端兼容版本，设置请求超时、最大尝试和凭证；发送时记录业务事件 ID、Topic、MessageGroup 与结果。消费成功后确认，失败按错误类型重试，并对重复投递做幂等。把堆积年龄、失败次数和死信作为业务告警。
下一步
继续阅读08-19 RocketMQ 存储源码与高可用集群，追踪消息怎样落盘和复制。