消息队列可靠性设计：不丢消息、幂等消费与顺序保证

“MQ 集群高可用”不等于“业务绝不会丢消息”。一条订单事件从数据库出发，经过客户端、网络、Broker、副本、消费者，最后写入库存库；任意边界都有失败窗口。

设计可靠消息链路，必须分别回答三个问题：消息是否到达并安全存入 Broker，Broker 是否把消息交给消费者，消费者的业务结果是否正确落地。

先定义“可靠”的边界

常见投递语义包括：

• 至多一次（at-most-once）：消息最多处理一次，允许丢失，不产生 Broker 层重投。
• 至少一次（at-least-once）：消息不会轻易丢，但故障和重试可能造成重复。
• 精确一次（exactly-once）：只在产品声明的特定作用域和前提下成立。跨越 MQ、数据库和外部接口后，通常仍需事务边界与业务幂等配合。

多数业务系统选择“至少一次投递 + 幂等消费”，得到业务效果上的一次。

消息可能在哪里丢失

故障位置	典型现象	保护机制	剩余风险
生产者发送	超时，不知道消息是否到达	confirm/ack、有限重试、稳定事件 ID	超时前可能已成功，重试会重复
业务库与发送之间	订单提交但消息没发出	Outbox、事务消息、补偿扫描	下游只能最终一致
Broker 存储	节点宕机、磁盘损坏	持久化、多副本、法定多数确认	副本同时失效或错误配置仍可能丢失
消费者接收	收到后进程崩溃	手动 ack、可见性超时、重投	业务可能已成功，产生重复
消费者处理	下游超时或部分成功	本地事务、幂等、重试、补偿	外部非事务副作用需额外去重

生产者到 Broker

生产者不能把“调用发送 API 返回”简单等同于安全落盘。可靠链路通常需要：

1. 使用客户端确认机制，等待 Broker 接管消息。
2. 为发送设置超时和有限重试。
3. 每次重试复用同一个 eventId。
4. 将超时视为“结果未知”，而不是肯定失败。

RabbitMQ 的 publisher confirms、Kafka 的 acks 配置、RocketMQ 的同步发送结果都在解决责任交接问题，但确认范围不同，应按官方语义配置。

Broker 内部存储与副本

持久化解决重启后的恢复，副本解决单节点失效，两者缺一不可。以现代 RabbitMQ 高可用为例，官方推荐使用基于 Raft 的 quorum queue；经典镜像队列已经废弃并在 RabbitMQ 4.0 移除。Kafka 和 RocketMQ 则围绕分区/队列进行副本复制与 leader 故障转移。

可靠性配置会增加网络、磁盘和确认延迟。副本数量、最小同步副本和确认级别必须一起设计，不能只打开“持久化”就宣称消息不会丢。

Broker 到消费者

消费者最危险的错误是提前确认：

收到消息 → 立即 ack → 执行业务 → 进程崩溃

此时 Broker 已删除或推进消费进度，业务却没有完成。正确顺序是：

收到消息 → 完成本地业务事务 → ack / 提交 offset

如果业务成功后、确认前进程崩溃，消息会重投。这不会丢消息，却会重复，因此可靠消费一定与幂等相伴。

高可用不等于消息绝不丢失

高可用描述系统在部分节点故障时能否继续服务；数据安全描述已经确认的数据能否保留；业务正确性描述最终副作用是否符合预期。

例如 RabbitMQ quorum queue 只有在 publisher confirm 返回、消息已复制到法定多数后，才进入其安全承诺范围；Kafka 的可靠性受生产者确认、同步副本集合、leader 选举和消费者提交共同影响。任何未确认的在途消息、错误的客户端处理或跨系统事务空隙，都不在“集群高可用”四个字的自动保护之内。

重复消费为什么必然需要考虑

假设库存服务已经扣减库存，但在提交消费进度前崩溃。重启后 Broker 只知道旧进度，于是再次投递。同样，生产者发送超时后重试，也可能在 Broker 中留下两条逻辑相同的事件。

重复并非 MQ 异常，而是至少一次语义用来对抗丢失的代价。业务需要回答的不是“怎样保证 MQ 从不重复”，而是“同一个业务事件执行多次，结果是否仍然正确”。

消费幂等的实现方式

常见手段按业务选择：

• 数据库写入使用业务唯一键或唯一索引。
• 状态更新使用条件表达式，例如仅允许 PAID → SHIPPED。
• 覆盖式 set 天然比累加操作更容易幂等。
• 建立已处理事件表，用 event_id 唯一约束去重。
• 调用外部系统时传递幂等键，并要求对方持久化去重结果。

下面的伪代码把去重记录和库存扣减放进同一个本地事务：

@Transactional
public void handle(OrderCreated event) {
    // processed_event.event_id 建有唯一索引
    if (!processedEventRepository.tryInsert(event.eventId())) {
        return; // 已经成功处理过
    }

    int changed = inventoryRepository.deductIfEnough(
        event.skuId(), event.quantity()
    );
    if (changed != 1) {
        throw new InsufficientInventoryException(event.skuId());
    }
}

public void onMessage(OrderCreated event, Acknowledgement ack) {
    handle(event); // 事务成功返回后
    ack.acknowledge();
}

不能采用“先查 Redis、处理业务、再写 Redis”这种无原子性的三步去重：两个消费者可能同时查到不存在并重复执行；业务成功但标记写入失败也会留下窗口。

数据库与消息的一致性

“订单写库”和“发送消息”属于两个资源，普通本地事务无法同时覆盖。常见方案如下：

方案	原理	优点	代价与边界
Transactional Outbox	业务数据与 outbox 同库同事务，后台可靠投递	与 MQ 产品解耦、边界清楚	需要投递器、清理、监控；仍可能重复
Broker 事务消息	预消息/半消息配合本地事务与回查	业务链路集成度高	依赖产品能力；只解决生产侧一致性，消费仍需幂等
本地事务 + 补偿扫描	记录状态，定时查漏补发	简单系统易落地	实时性较弱，补偿逻辑和审计要求高

RocketMQ 官方也明确指出，事务消息保证上游本地事务与消息提交的最终一致，不自动保证下游消费结果；消费者仍要重试和幂等。

顺序消息的边界

全局顺序意味着所有消息通过一条串行通道，吞吐和可用性都会受到限制。绝大多数业务真正需要的是同一业务键的局部顺序：同一订单的“创建、支付、取消”必须有序，不同订单可以并行。

实现步骤通常是：

1. 生产者始终用 orderId 作为路由键。
2. 相同键进入同一 partition、message queue 或有序消息组。
3. 分区内单线程或串行处理同一键。
4. 失败消息处理完成或进入明确的隔离路径后，才继续后续消息。

RocketMQ 5.x 以 message group 表达局部 FIFO；Kafka 保证 partition 内记录顺序。顺序不只取决于 Broker：生产者并发重试、消费者异步线程池、批处理部分失败和业务数据库并发更新都可能造成最终乱序。

对于状态型业务，还可以用版本号兜底：只接受比当前版本新的事件，旧事件到达时忽略或进入审计队列。

失败处理与死信策略

重试前先分类：

• 网络抖动、短时限流等瞬时故障，采用有上限的指数退避并加入随机抖动。
• 参数错误、数据缺失等永久故障，直接进入死信或人工处理。
• 下游整体故障，暂停或降低消费速率，避免重试风暴继续压垮下游。

死信队列不是垃圾桶。每条死信都要保留原消息、异常摘要、重试次数、首次/末次失败时间和处理版本，并提供查询、修复、重放与审计流程。重放前仍要确认消费者幂等。

可靠性设计清单

• 为每条业务事件生成稳定且全局唯一的 eventId。
• 生产者等待恰当的 Broker 确认，并记录结果未知的发送。
• 业务事务与消息发送使用 Outbox、事务消息或可审计补偿。
• Broker 开启持久化、副本和符合 RPO 的确认策略。
• 消费者关闭不合适的自动确认，在业务成功后确认。
• 用数据库约束或原子状态机实现幂等，而非仅靠内存判断。
• 以业务键定义顺序范围，不追求不必要的全局顺序。
• 为重试设置分类、上限、退避、死信和人工恢复流程。

面试回答要点

回答可靠性问题时按“生产者—Broker—消费者”展开：生产者确认和重试；Broker 持久化、副本和故障转移；消费者成功后确认、失败重投，再用业务唯一键保证幂等。随后主动补充数据库与消息的一致性方案，以及顺序通常只保证到同一业务键或分区。

这种回答比背一组配置项更完整，因为它明确了每个保证的作用域与剩余风险。

总结

可靠消息不是一个开关，而是一条端到端责任链。确认与副本减少丢失，重试提高到达概率，同时制造重复；幂等把重复变得安全；路由键和串行边界提供局部顺序；Outbox 或事务消息连接数据库与 MQ。只有这些机制共同工作，Broker 的高可用才能转化为业务正确性。

参考资料

• Advanced Java：消息队列专题
• RabbitMQ Reliability Guide
• RabbitMQ Quorum Queues
• Apache Kafka Documentation
• Apache RocketMQ：Ordered Message
• Apache RocketMQ：Transaction Message