异步与消息架构 ​

消息队列不是「为了用而用」。它解决的是三个具体问题：解耦、削峰、最终一致 —— 如果这三个都不沾，就别引入。 Kafka 的存储与副本细节见 Kafka 深入，这篇讲架构层面怎么用。

一、先判断：该不该异步 ​

判断标准一句话：调用方需不需要立刻用这个结果。不需要，就可以异步。

异步的三种代价 ​

1. 复杂度：从「一次调用」变成「两个系统 + 一个中间件」，排查链路变长；
2. 一致性：从「事务内」变成「最终一致」，必须设计补偿；
3. 延迟：正常情况多几十毫秒，异常时可能积压几十分钟。

二、四种模型 ​

三、中间件选型（速查） ​

一句话选型：日志/埋点/流处理 → Kafka；业务消息 + 事务 + 延迟 → RocketMQ；量不大、路由复杂 → RabbitMQ。

四、可靠性：还是那三件事 ​

不丢、不重、不乱序 —— 具体配置见 Kafka 深入 · 第 6 节，这里只列架构层面的兜底：

记住一句：MQ 只保证「至少一次」，业务必须自己幂等。

五、事务消息与本地消息表 ​

「本地事务成功，消息一定发出去」—— 这是最容易出问题的地方。

方案 A：本地消息表（最通用，不依赖 MQ 特性） ​

1. 业务事务里，同时往「消息表」插一条 status=待发送
2. 事务提交后，异步任务扫表发送 MQ
3. 发送成功 → 状态改「已发送」；失败 → 重试（指数退避）
4. 定时任务补偿卡在「待发送」超过 N 分钟的记录
5. 消费端幂等（用消息表主键去重）

1. 业务事务里，同时往「消息表」插一条 status=待发送
2. 事务提交后，异步任务扫表发送 MQ
3. 发送成功 → 状态改「已发送」；失败 → 重试（指数退避）
4. 定时任务补偿卡在「待发送」超过 N 分钟的记录
5. 消费端幂等（用消息表主键去重）

优点：任何 MQ 都能用、可靠、易排查。 缺点：多一张表、有延迟、扫表要控制频率。

方案 B：RocketMQ 事务消息 ​

1. 发 half message（对消费端不可见）
2. 执行本地事务
3. 提交/回滚 half message
4. 若第 3 步没到达，Broker 回查本地事务状态

1. 发 half message（对消费端不可见）
2. 执行本地事务
3. 提交/回滚 half message
4. 若第 3 步没到达，Broker 回查本地事务状态

优点：不用自己扫表。 缺点：绑定 RocketMQ，且回查逻辑要幂等。

方案 C：Outbox + CDC（大厂做法） ​

业务表 + outbox 表同库，用 Canal/Debezium 订阅 binlog 投递 MQ。业务代码零侵入，但有运维成本。

六、延迟消息怎么实现 ​

订单超时取消的推荐组合：延迟消息（快）+ 定时扫表（兜底，防止消息丢了）。

七、积压怎么处理 ​

先查三件事：消费者是不是挂了、是不是在反复重试同一条毒消息、下游依赖是不是慢了。

八、四个常见反模式 ​

1. 用 MQ 做 RPC（请求-应答、同步等结果）→ 延迟高、失败难处理，直接 HTTP 更好。
2. 消息体塞整个实体（几 MB）→ 只发 ID，消费方回查；大消息会拖垮 Broker。
3. 没有死信队列 → 毒消息无限重试，把整个 topic 堵死。
4. 消费端不幂等 + 生产端重试 → 重复数据，事后对账一地鸡毛。

九、速查 ​