怎么进行RabbitMQ消息的可靠投递
怎么进行RabbitMQ消息的可靠投递，针对这个问题，这篇文章详细介绍了相对应的分析和解答，希望可以帮助更多想解决这个问题的小伙伴找到更简单易行的方法。
mq 提供了两种方式确认消息的可靠投递
confirmCallback 确认模式
returnCallback 未投递到 queue 退回模式
在使用 RabbitMQ 的时候，作为消息发送方希望杜绝任何消息丢失或者投递失败场景。RabbitMQ 为我们提供了两个选项用来控制消息的投递可靠性模式。
rabbitmq 整个消息投递的路径为：
producer->rabbitmq broker cluster->exchange->queue->consumer
message 从 producer 到 rabbitmq broker cluster 则会返回一个 confirmCallback 。
message 从 exchange->queue 投递失败则会返回一个 returnCallback 。我们将利用这两个 callback 控制消息的最终一致性和部分纠错能力。
对于消息异常，可以使用以下方法进行解决
使用RepublishMessageRecoverer这个MessageRecoverer会发送发送消息到指定队列
给队列绑定死信队列，因为默认的RepublishMessageRecoverer会发送nack并且requeue为false。这样抛出一场是这种方式和上面的结果一样都是转发到了另外一个队列。详见DeadLetterConsumer
注册自己实现的MessageRecoverer
给MessageListenerContainer设置RecoveryCallback
对于方法手动捕获异常，进行处理
rabbitTemplate的发送流程是这样的：
1 发送数据并返回(不确认rabbitmq服务器已成功接收)
2 异步的接收从rabbitmq返回的ack确认信息
3 收到ack后调用confirmCallback函数
注意： 在confirmCallback中是没有原message的，所以无法在这个函数中调用重发，confirmCallback只有一个通知的作用。
最安全的做法是是使用事务，但是这样效率就会很低，每秒钟处理的message在几百条左右。对于高性能的 mq 来说是非常不可取的。
另一种解决方法如下：在rabbitTemplate异步确认的基础上
1 在本地缓存已发送的 message
2 通过 confirmCallback 或者被确认的 ack，将被确认的message从本地删除
3 定时扫描本地的message，如果大于一定时间未被确认，则重发
这种解决方式也有一定的问题：
想象这种场景，rabbitmq接收到了消息，在发送ack确认时，网络断了，造成客户端没有收到ack，重发消息。（相比于丢失消息，重发消息要好解决的多，我们可以在consumer端做到幂等）。
关于怎么进行RabbitMQ消息的可靠投递问题的解答就分享到这里了，希望以上内容可以对大家有一定的帮助，如果你还有很多疑惑没有解开，可以关注行业资讯频道了解更多相关知识。
