后端消息投递可靠性：基于 RabbitMQ 的“双重防线-幂等闭环”模式

后端消息投递可靠性：基于 RabbitMQ 的“双重防线-幂等闭环”模式

一、 发送核心：rabbitTemplate.convertAndSend重载全览

在 RabbitMQ 的“中控-工人”模式中，中控（生产者）发送指令的形式决定了任务的可靠性深度。

1. 基础目的地形式

• convertAndSend(Object message): 使用模板配置的默认 Exchange 和 Routing Key。
• convertAndSend(String routingKey, Object message): 发送到默认 Exchange，手动指定路由键。
• convertAndSend(String exchange, String routingKey, Object message):最常用，完整定义指令的去向。

2. 消息后处理器 (MessagePostProcessor)

允许在消息发送前的最后时刻挂载额外属性（如：任务优先级、TTL 过期时间）。

• 案例:

  rabbitTemplate.convertAndSend("ex.task","key.urgent",taskData,message->{message.getMessageProperties().setPriority(10);// 设置高优先级message.getMessageProperties().setHeader("trace-id","uuid-123");returnmessage;});

3. 可靠性追踪形式 (CorrelationData)

这是实现“发送确认”的唯一入口，用于追踪每一条指令的抵达状态。

• 形式:convertAndSend(..., CorrelationData correlationData)

二、 第一道防线：CorrelationData 与 ConfirmCallback

这一组机制用于解决“指令是否成功到达交换机（Exchange）”的问题（针对网络、连接或 Broker 状态）。

1. 核心逻辑：运单号模式

CorrelationData相当于快递的存根（运单号）。中控发送任务后手持存根，当 RabbitMQ 签收后，会异步回传该 ID 的确认信息。

2. 落地步骤

1. 开启配置:spring.rabbitmq.publisher-confirm-type: correlated。
2. 发送存根:

   // 每一个任务生成一个唯一 IDCorrelationDatacd=newCorrelationData("TASK_ORDER_001");rabbitTemplate.convertAndSend("ex.direct","key.db",orderData,cd);

3. 设置回调用于全局监听:

   rabbitTemplate.setConfirmCallback((correlationData,ack,cause)->{Stringid=correlationData!=null?correlationData.getId():"";if(ack){// 代表 Exchange 已签收，中控可以更新本地任务状态为“已送达”}else{// 代表 Broker 拒绝（如磁盘满），触发人工干预或预警}});

3. 关键细节

• 局限性:ack=true只代表交换机收到了，并不保证消息一定进入了队列或被消费了。
• 异步性: 这是一个异步过程，不会阻塞主线程。

三、 第二道防线：Mandatory 与 ReturnsCallback

这一组机制用于解决“指令是否在交换机内部成功路由到队列（Queue）”的问题。

1. 为什么它是必选的？

即便ConfirmCallback返回了ack=true，如果中控手抖写错了routingKey，消息在交换机内部会被直接丢弃。

2. 操作细节

• setMandatory(true): 告诉 Broker：“如果路由失败，不要偷偷扔掉，必须退还给我。”
• setReturnsCallback: 定义退还后的处理逻辑（如：记录无效路由日志、修正路由键）。

四、 核心总结：两组回调的“职责边界”

我们将复杂的 API 抽象为两组互补的防线：

五、 生产级闭环：重新投递与幂等性

开启上述确认机制后，必然会面临“重复发送”的风险（例如 ACK 回传时网络闪断）。因此，必须构建幂等闭环。

1. 至少投递一次 (At Least Once)

当ConfirmCallback收到ack=false或确认超时时，中控需要利用CorrelationData中的 ID 重新发送任务。

2. 消费者的幂等策略

既然“重复投递”在分布式环境下是必然发生的，工人（消费者）必须具备去重能力：

• 强一致性场景: 利用数据库唯一主键（如订单号）拦截。
• 高并发场景: 利用Redis SETNX（设置消息 ID 为 Key）进行预检。
• 业务逻辑场景: 检查状态机（如果任务状态已是“进行中/已完成”，则直接跳过本次指令）。

3. 最终结论

• 防线配置是为了确保消息**“不丢失”**。
• 幂等处理是为了确保消息**“不重做”**。
  两者的结合，才是完整、健壮的后端异步任务编排方案。