后端消息投递可靠性：基于 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 过期时间）。

案例 :

java 复制代码

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. 落地步骤

开启配置 : spring.rabbitmq.publisher-confirm-type: correlated。

发送存根 :

java 复制代码

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

设置回调用于全局监听 :

java 复制代码

rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {
    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 抽象为两组互补的防线：

维度	第一组：确认防线 (Confirms)	第二组：路由防线 (Returns)
组合参数	`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. 最终结论

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

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