RabbitMQ高级篇之发送者可靠性 发送者确认的代码实现

文章目录

• • • 一、配置文件中启用确认机制
    • 二、编写 `returnCallback` 和 `confirmCallback`
    • 三、消息确认测试
    • 四、性能注意事项
    • 总结

一、配置文件中启用确认机制

1. 在 application.yml 或 application.properties 文件中开启 publish confirm 和 publish return：
   • publish confirm 有三个模式：
     • null：关闭（默认）。
     • simple：同步阻塞模式。
     • correlated：异步模式。
   • publish return 默认为 false，需要显式设置为 true。

二、编写 returnCallback 和 confirmCallback

1. returnCallback 的实现：

   • 创建一个配置类 MqConfig，通过构造函数注入 RabbitTemplate。
   • 使用 @PostConstruct 注解初始化函数，在容器加载完成后给 RabbitTemplate 添加 ReturnCallback。
   • ReturnCallback 是一个接口，处理返回的消息。可以使用 Lambda 表达式简化代码：
     
     

2. confirmCallback的实现：

   • 在发送消息时指定 confirmCallback，需要为每次发送的消息创建 CorrelationData，并指定消息 ID 和回调。
   • 通过 ListenableFutureCallback异步处理确认结果：

三、消息确认测试

1. 测试发送成功的情况：
   • 确保发送的消息成功投递并返回 ack，测试时确保日志级别设置为 DEBUG，以便查看确认信息。
2. 测试发送失败的情况：
   • 测试路由失败的场景，如 routingKey错误，RabbitMQ 会通过 returnCallback返回失败信息，并记录 replyCode和 replyText。
3. 测试 nack 返回：
   • 在发送消息时，若交换机配置错误或消息未成功持久化，RabbitMQ 会返回 nack，需要记录失败原因并考虑重试机制。

四、性能注意事项

• 发送者确认机制由于需要与 RabbitMQ 进行双向通信，会显著影响消息发送的性能。大多数情况下，消息发送出现异常的概率较低，因此通常不建议启用此机制，除非确有需求。
• 若启用确认机制，需要设置合理的重试次数，避免无限重试造成性能下降。

总结

• 发送者确认机制由 publish confirm 和 publish return 两部分组成，能够提高消息发送的可靠性。
• returnCallback 和 confirmCallback用来处理消息发送失败的情况，提供消息投递失败的原因。
• 该机制虽能提高可靠性，但会影响系统性能，因此要谨慎使用，并合理设置重试机制。