RabbitMQ高级篇之发送者可靠性 发送者确认机制

一、发送者确认机制概述

Spring AMQP 提供了 publish confirm 和 publish return 两种确认机制。通过开启这些机制，发送方发送消息给 RabbitMQ 时，RabbitMQ 会根据消息处理的结果返回一个确认结果给发送者。确认机制可以有效提高消息发送的可靠性。

二、发送确认机制的工作原理

1. Publish Return
   当消息投递到 RabbitMQ 时，如果发生路由失败，RabbitMQ 会通过 publish return 返回失败的原因，同时通过 publish confirm 返回一个确认结果（ack）。
   • 路由失败：如果消息不能路由到任何队列（如交换机没有绑定队列），RabbitMQ 会返回 ack，表示消息投递成功，但由于路由失败，消息无法被消费。这通常是由于程序员配置错误（如交换机没有绑定队列）造成的。
   • 临时消息和持久消息：
     • 临时消息：不需要持久化，消息投递到队列即算成功，返回 ack。
     • 持久消息：需要持久化到磁盘，只有在成功持久化后才返回 ack，否则返回 nack。

2. Publish Confirm
   • publish confirm 机制用来确认消息是否成功被投递到 RabbitMQ。消息发送者需要等到 RabbitMQ 的确认结果（ack 或 nack）才认为消息发送成功。
   • 该机制通过回调函数异步获取消息确认结果，如果收到 nack，可以重试发送消息。

三、确认机制的启用

1. 开启 publish confirm 和 publish return
   • 配置方式：
     在 application.yml 或 application.properties 文件中配置以下内容：

spring：
  rabbitmq：
    publisher-confirm-type: correlated	# 开启 publisher confirm 机制，并设置 confirm 类型
    publisher-returns: true	# 开启 publisher return 机制

• • publish return 默认为 false，需要显式开启。
  • publish confirm type 需要配置确认模式：
    • non：没有确认机制，默认关闭。
    • simple：同步阻塞模式（等待确认返回后再继续执行）。
    • correlated：异步模式（设置回调函数，确认结果返回后异步处理）。

四、确认机制的实现

1. publish return 的回调配置
   • 使用 returnCallback 配置，在 RabbitTemplate 中设置 ReturnCallback。
   • 示例代码：

@Slf4j
@Configuration
@RequiredArgsConstructor
public class MqConfig {

    private final RabbitTemplate rabbitTemplate;

    @PostConstruct
    public void init() {
        rabbitTemplate.setReturnsCallback(returned -> {
            log.error("监听到了消息 return callback");
            log.debug("exchange: {}", returned.getExchange());
            log.debug("routingKey: {}", returned.getRoutingKey());
            log.debug("message: {}", returned.getMessage());
            log.debug("replyCode: {}", returned.getReplyCode());
            log.debug("replyText: {}", returned.getReplyText());
        });
    }
}

2. publish confirm 的回调配置
   • 使用 ConfirmCallback 配置，在发送消息时指定消息确认回调。
   • 示例代码：

五、消息确认模式详解

1. 同步阻塞式确认（simple）
   • 在发送消息时，RabbitTemplate 会等待 RabbitMQ 返回确认结果。如果没有确认结果，发送者会阻塞等待。
   • 适合对消息投递可靠性要求较高的场景，但性能较低。
2. 异步确认（correlated）
   • 发送消息时，使用回调函数来处理确认结果，不会阻塞主线程。
   • 适合高性能场景，能够异步处理消息确认结果。

六、常见问题与优化

1. 性能问题：
   • 同步阻塞模式会影响消息发送的性能，尤其是在高并发场景下。可以通过设置合理的超时时间和重试次数来优化。
   • 异步模式通过回调函数异步处理确认结果，不会阻塞主线程，适合高性能需求的应用。
2. 消息重发：
   • 在收到 nack 后，通常需要重新发送消息。可以通过记录失败的消息并异步重发来提高系统的可靠性。

七、总结

• 发送确认机制可以通过 publish confirm 和 publish return 提高消息发送的可靠性，防止消息丢失。
• publish confirm 机制确认消息是否成功投递，而 publish return 机制确认消息是否能够被正确路由。
• 配置时需注意选择合适的确认模式，平衡可靠性与