Apache RocketMQ: Backend Message Middleware
NameServer and Broker topology, message types, transaction messages, delayed messages, retry and dead letter topics.
Topology: NameServer + Broker + Producer/Consumer
# 启动顺序：NameServer → Broker → 应用
nohup sh bin/mqnamesrv & # 注册中心（无状态，可多部署）
nohup sh bin/mqbroker -n localhost:9876 & # 真正存消息的节点
# 队列模型：每个 topic 有多个队列（MessageQueue）
# 顺序消费场景把同 key 消息发到同队列
# 主从同步（SYNC_MASTER）+ 刷盘方式决定可靠性：
# flushDiskType=SYNC_FLUSH（同步刷盘最稳）/ ASYNC_FLUSH（性能优先）
# 与 Kafka 的结构差异：
# 无 ZK，NameServer 极轻；CommitLog 单文件存储 + ConsumeQueue 索引
# 原生支持延迟队列、事务消息、消息轨迹、重试机制Message Types
| 类型 | 用途 | 备注 |
|---|---|---|
| 普通消息 | 默认异步解耦 | 无特殊语义 |
| 顺序消息 | 同 key 严格有序 | 生产者按 shardingKey 选队列 |
| 延迟消息 | 定时任务替代 | 18 个内置级别（1s~2h）；5.x 支持任意时间 |
| 事务消息 | 本地事务 + 投递原子性 | 半消息 + 回查 |
| 重试/死信 | 消费失败兜底 | %DLQ%CONSUMER_GROUP 人工处理 |
Transaction Messages: Half Message + Checkback
1. Producer 发「半消息」→ Broker 存储但对消费者不可见
2. 执行本地事务（扣库存、写库）
3. 本地成功 → commit → 半消息转可投递
本地失败 → rollback → 删除半消息
4. 超过超时时间未 commit/rollback → Broker 主动回查 Producer
回查返回 COMMIT / ROLLBACK / UNKNOWN（继续回查）
Java：实现 TransactionListener；send 用 TransactionMQProducer
适用：必须「库改了消息才发出去」的强一致场景
前提：回查接口要幂等、有状态记录可查
（其他模型通常用「本地消息表 + 对账」达到同等效果）Consumption and Retry
两种消费模式：
CLUSTERING（默认）：同组各消费者分摊队列，每条被处理一次
BROADCASTING：同组每个消费者都收到全量
消费失败的重试机制（开箱即用）：
RECONSUME_LATER → 进入 %RETRY%消费组
按延迟梯度重投（1s 5s 10s 30s 1m 2m ... 共 16 次）
超过最大次数 → %DLQ%消费组，留待人工
幂等还是必须自己保证：
消息可能因宕机/重平衡重复投递
常用手段：业务唯一键 + 去重表/Redis SETNX
推模式（默认）：Broker 长轮询推给消费者
拉模式：批量捞取，适合超大积压回放Dead letter topics accumulate until humans intervene — alert on their depth; a full DLQ means a code path or downstream dependency is broken.
拓扑：NameServer + Broker
# 启动顺序：NameServer → Broker → 应用
nohup sh bin/mqnamesrv & # 注册中心（无状态，可多部署）
nohup sh bin/mqbroker -n localhost:9876 & # 真正存消息的节点
# 队列模型：每个 topic 有多个队列（MessageQueue）
# 顺序消费场景把同 key 消息发到同队列
# 主从同步（SYNC_MASTER）+ 刷盘方式决定可靠性：
# flushDiskType=SYNC_FLUSH（同步刷盘最稳）/ ASYNC_FLUSH（性能优先）
# 与 Kafka 的结构差异：
# 无 ZK，NameServer 极轻；CommitLog 单文件存储 + ConsumeQueue 索引
# 原生支持延迟队列、事务消息、消息轨迹、重试机制消息类型
| 类型 | 用途 | 备注 |
|---|---|---|
| 普通消息 | 默认异步解耦 | 无特殊语义 |
| 顺序消息 | 同 key 严格有序 | 生产者按 shardingKey 选队列 |
| 延迟消息 | 定时任务替代 | 18 个内置级别（1s~2h）；5.x 支持任意时间 |
| 事务消息 | 本地事务 + 投递原子性 | 半消息 + 回查 |
| 重试/死信 | 消费失败兜底 | %DLQ%CONSUMER_GROUP 人工处理 |
事务消息：半消息与回查
1. Producer 发「半消息」→ Broker 存储但对消费者不可见
2. 执行本地事务（扣库存、写库）
3. 本地成功 → commit → 半消息转可投递
本地失败 → rollback → 删除半消息
4. 超过超时时间未 commit/rollback → Broker 主动回查 Producer
回查返回 COMMIT / ROLLBACK / UNKNOWN（继续回查）
Java：实现 TransactionListener；send 用 TransactionMQProducer
适用：必须「库改了消息才发出去」的强一致场景
前提：回查接口要幂等、有状态记录可查
（其他模型通常用「本地消息表 + 对账」达到同等效果）消费与重试
两种消费模式：
CLUSTERING（默认）：同组各消费者分摊队列，每条被处理一次
BROADCASTING：同组每个消费者都收到全量
消费失败的重试机制（开箱即用）：
RECONSUME_LATER → 进入 %RETRY%消费组
按延迟梯度重投（1s 5s 10s 30s 1m 2m ... 共 16 次）
超过最大次数 → %DLQ%消费组，留待人工
幂等还是必须自己保证：
消息可能因宕机/重平衡重复投递
常用手段：业务唯一键 + 去重表/Redis SETNX
推模式（默认）：Broker 长轮询推给消费者
拉模式：批量捞取，适合超大积压回放死信主题只会堆积等人处理——给它的深度配告警；DLQ 涨爆通常意味着某段代码或下游依赖坏了。