RabbitMQ消息可靠投递与策略模式实践

1. RabbitMQ消息可靠投递与策略模式实践

在分布式系统中，消息队列的可靠性直接关系到业务数据的一致性。最近我在重构一个社交平台的点赞功能时，就遇到了Redis缓存与数据库不一致的问题：用户点赞后，Redis计数立即更新，但MQ消息丢失导致数据库未能同步。这种"缓存超前"现象会随着时间推移产生越来越大的数据偏差。

经过排查，发现问题出在RabbitMQ生产者端的消息确认机制上。当网络抖动或Broker异常时，消息可能根本未到达交换机，但生产者却无法感知这个失败。本文将分享如何通过Spring AMQP的回调机制结合策略模式，实现业务级的消息可靠投递方案。

2. 消息投递的三种状态与风险

2.1 RabbitMQ消息生命周期

一个消息从生产者到消费者的完整路径要经历几个关键节点：

1. 生产者 → 交换机（Exchange）
2. 交换机 → 队列（Queue）
3. 队列 → 消费者

在Spring AMQP中，RabbitTemplate提供了两个关键回调接口来监控前两个阶段：

java复制// 消息是否到达交换机
rabbitTemplate.setConfirmCallback((correlationData, ack, cause) -> {
    if(!ack) {
        log.error("消息未到达交换机，原因：{}", cause);
    }
});

// 消息到达交换机但未路由到队列
rabbitTemplate.setReturnsCallback(returned -> {
    log.error("消息未路由到队列：{}", returned.getMessage());
});

2.2 典型数据不一致场景

以点赞功能为例，看看没有回调机制时会发生什么：

1. 用户点赞 → Redis执行SADD操作
2. 发送MQ消息 → 网络丢包导致消息未到达交换机
3. 数据库永远收不到这条点赞记录

结果：Redis计数比实际数据库多1，且无法自动修复。当缓存失效后重新加载，用户会发现自己的点赞"消失"了。

3. 策略模式实现差异化补偿

3.1 简单实现的局限性

最直观的做法是在ConfirmCallback里写一堆if-else：

`