MQ高级1：消息可靠性问题、生产者可靠性
欢迎来到“雪碧聊技术”CSDN博客！
在这里，您将踏入一个专注于Java开发技术的知识殿堂。无论您是Java编程的初学者，还是具有一定经验的开发者，相信我的博客都能为您提供宝贵的学习资源和实用技巧。作为您的技术向导，我将不断探索Java的深邃世界，分享最新的技术动态、实战经验以及项目心得。
让我们一同在Java的广阔天地中遨游，携手提升技术能力，共创美好未来！感谢您的关注与支持，期待在“雪碧聊技术”与您共同成长！
目录
一、消息可靠性问题
1、什么是消息可靠性问题？
2、造成消息不可靠的三个因素
①生产者：发送消息时，造成消息丢失
②MQ（交换机+队列）：消息队列自己把消息弄丢了
③消费者：消费者监听消息时，把消息弄丢了
3、如何解决消息可靠性问题？
①生产者的可靠性
②MQ的可靠性
③消费者的可靠性
④延迟消息（兜底方案，以上方案都失败时，可采用此方案）
二、生产者可靠性
1、生产者重连（确保成功连接到rabbitMQ服务）
举例：我们把docker容器关闭（即关闭rabbitMQ进程），然后使用Java客户端发送消息到MQ，看看是否会重试连接MQ
2、生产者确认（确认生产者将消息发送给了MQ）
①返回ACK（成功）的三种情况
②返回NACK（失败）的情况
3、SpringAMQP实现生产者确认（简单看看就行，理解即可）
①在生产者（publisher）对应的微服务的配置文件中，添加如下配置
②每个RabbitTemplate只能配置一个ReturnCallback，因此需要在项目启动过程中进行配置（即：编写成配置类）
③发送消息时，指定消息ID、消息的ConfirmCallback
4、总结
一、消息可靠性问题
1、什么是消息可靠性问题？
一个消息被发送出去，至少会被消费一次，即：消息不会丢失。
说白了，消息可靠就是消息不会丢失。
2、造成消息不可靠的三个因素
①生产者：发送消息时，造成消息丢失
②MQ（交换机+队列）：消息队列自己把消息弄丢了
③消费者：消费者监听消息时，把消息弄丢了
3、如何解决消息可靠性问题？
有如下四个方案：
①生产者的可靠性
②MQ的可靠性
③消费者的可靠性
④延迟消息（兜底方案，以上方案都失败时，可采用此方案）
二、生产者可靠性
1、生产者重连（确保成功连接到rabbitMQ服务）
有时候由于网络波动，可能会出现客户端连接MQ失败的情况。通过配置我们可以开启连接失败后的重连机制：
注意：以上是我们的Java客户端连接MQ时失败后的重试，而不是发送者发送消息失败后的重试。
举例：我们把docker容器关闭（即关闭rabbitMQ进程），然后使用Java客户端发送消息到MQ，看看是否会重试连接MQ
- 第一步：关闭docker容器，故意让java客户端连接不上rabbitMQ（模拟网络波动导致rabbitMQ连接不上的情况）
# 关掉docker容器mq，停止rabbitMQ进程
docker stop mq
- 第二步：配置客户端生产者重连
- 第三步：编写代码，往MQ发送消息
- 第四步：查看控制台，是否有重连MQ的日志信息
2、生产者确认（确认生产者将消息发送给了MQ）
RabbitMQ提供了Publisher Confirm和Publisher Return两种确认机制。开启确认机制后，在MQ成功收到消息后，会返回确认消息给生产者，表示生产者确实将消息发送给了MQ。返回结果有如下几种情况：
①返回ACK（成功）的三种情况
- 生产者将消息成功投递到了MQ，但是MQ中的路由器发生故障。此时会通过PublisherReturn返回路由异常原因，然后返回ACK，告知生产者投递成功。（因为此时生产者确实成功将消息发送到了MQ，只是MQ中的路由器发生了问题，因此和人家生产者没有关系）
- 生产者将临时消息发送到了MQ，并且成功进入队列，此时会返回ACK，告知生产者投递成功。
- 生产者将持久消息发送到了MQ，并且成功进入队列、完成持久化，此时会返回ACK，告知生产者投递成功。
②返回NACK（失败）的情况
除了上述三种情况，都会返回NACK。
3、SpringAMQP实现生产者确认（简单看看就行，理解即可）
步骤如下：
①在生产者（publisher）对应的微服务的配置文件中，添加如下配置
②每个RabbitTemplate只能配置一个ReturnCallback，因此需要在项目启动过程中进行配置（即：编写成配置类）
③发送消息时，指定消息ID、消息的ConfirmCallback
4、总结
可见，生产者确认机制不推荐使用，因此我们上面的SpringAMQP实现生产者确认的过程只是看看就行，简单了解下即可。
以上就是本篇文章的全部内容，想了解更多的RabbitMQ知识，请关注本博主~~