后端消息投递可靠性：基于 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");
return message;
});
3. 可靠性追踪形式 (CorrelationData)
这是实现“发送确认”的唯一入口，用于追踪每一条指令的抵达状态。
- 形式: convertAndSend(…, CorrelationData correlationData)
二、 第一道防线：CorrelationData 与 ConfirmCallback
这一组机制用于解决 “指令是否成功到达交换机（Exchange）” 的问题（针对网络、连接或 Broker 状态）。
1. 核心逻辑：运单号模式
CorrelationData 相当于快递的存根（运单号）。中控发送任务后手持存根，当 RabbitMQ 签收后，会异步回传该 ID 的确认信息。
2. 落地步骤
CorrelationData cd = new CorrelationData("TASK_ORDER_001");
rabbitTemplate.convertAndSend("ex.direct", "key.db", orderData, cd);
String id = 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 抽象为两组互补的防线：
| 组合参数 | CorrelationData + ConfirmCallback | mandatory=true + ReturnsCallback |
| 监控范围 | 中控 →\\rightarrow→ 交换机 (Exchange) | 交换机 →\\rightarrow→ 工人队列 (Queue) |
| 判定逻辑 | 解决“消息丢没丢” | 解决“地址对不对” |
| 关键结论 | 只要 Exchange 存在，ACK 就会触发。 | 只有在路由失败时，Return 才会触发。 |
五、 生产级闭环：重新投递与幂等性
开启上述确认机制后，必然会面临“重复发送”的风险（例如 ACK 回传时网络闪断）。因此，必须构建幂等闭环。
1. 至少投递一次 (At Least Once)
当 ConfirmCallback 收到 ack=false 或确认超时时，中控需要利用 CorrelationData 中的 ID 重新发送任务。
2. 消费者的幂等策略
既然“重复投递”在分布式环境下是必然发生的，工人（消费者）必须具备去重能力：
- 强一致性场景: 利用数据库唯一主键（如订单号）拦截。
- 高并发场景: 利用 Redis SETNX（设置消息 ID 为 Key）进行预检。
- 业务逻辑场景: 检查状态机（如果任务状态已是“进行中/已完成”，则直接跳过本次指令）。
3. 最终结论
- 防线配置是为了确保消息**“不丢失”**。
- 幂等处理是为了确保消息**“不重做”**。
两者的结合，才是完整、健壮的后端异步任务编排方案。
