消息类型与消费语义
普通消息
普通消息适合没有特殊时序要求的事件。Producer 重试、网络超时和 Consumer 重投都可能造成重复，业务必须按 At-Least-Once 设计幂等。
顺序消息
RocketMQ 的顺序以 MessageGroup 或同一 MessageQueue 为边界，不提供跨全部队列的全局顺序。要保证订单内顺序，应让同一订单的消息稳定进入同一顺序组，并由消费者串行处理该组。
严格顺序会牺牲并发；某条消息持续失败还可能阻塞同组后续消息，应设计异常隔离和人工处理。
延时消息
5.x 定时/延时消息可按目标投递时间调度。它适合订单超时、延迟检查等场景，但不是精确实时调度器：Broker 压力、时钟和投递重试都会影响实际可见时间。
延时消息在到期前通常不能按普通消息立即消费，保留时间、最大延迟范围和版本能力需要按部署核对。
事务消息
事务消息通过 Half Message、执行本地事务、提交/回滚以及 Broker 回查协调最终状态。
RocketMQ 事务消息不等于分布式数据库事务。Producer 的本地事务和回查必须幂等，Consumer 也仍需幂等。
重试与死信
消费失败后，Broker 按 Consumer Group 维护重试消息；达到最大重试次数后进入死信队列。重试间隔和次数受客户端类型、消费模式及服务端版本影响。
处理死信时应保留 Message ID、Key、原 Topic、Consumer Group、失败异常和业务状态。死信重新投递前必须确认问题已修复，否则会再次形成积压。
Offset 与消费确认
Push Consumer 本质上由客户端封装拉取、缓存与线程池。消费回调成功后推进消费进度；失败或超时可能触发重投。
5.x SimpleConsumer 提供更显式的 Receive/Ack 行为。消息不可见时间内未 Ack，会再次变为可投递，因此处理时间必须与 Invisible Duration 配合。
幂等设计
常见方法包括业务唯一键、数据库唯一约束、消费记录表、条件状态更新和事务性 Outbox。Message ID 可用于追踪，但是否适合作为业务唯一键要结合重试和消息生成方式判断。