目录RabbitMQ高级篇发送者可靠性-发送者重连发送者可靠性-发送者确认MQ可靠性-数据持久化MQ可靠性-Lazy Queue消费者可靠性-消费者确认消费者可靠性-失败重试失败消息处理策略消费者可靠性-业务幂等性唯一消息idRabbitMQ高级篇发送者可靠性-发送者重连由于网络波动可能会出现发送者连接MQ失败的情况。通过配置我们可以开启连接失败后的重连机制注意当网络不稳定的时候利用重试机制可以有效提高消息发送的成功率。不过SpringAMQP提供的重试机制是阻塞式的重试也就是说多次重试等待过程中当前线程是被阻塞的影响业务性能如果业务对性能高有要求建议禁用重试机制也可以考虑使用异步线程来执行发送消息的代码发送者可靠性-发送者确认SpirngAMQP提供了Publisher Confirm和Publisher Return两种确认机制。开启确认机制后当发送者发送消息给MQ后MQ会返回确认结果给发送者。返回结果有以下几种情况消息投递到了MQ但是路由失败。此时会通过PublisherReturn返回路由异常原因然后返回ACK告知投递成功临时消息投递到了MQ并且入队成功返回ACK告知投递成功持久消息投递到了MQ并且入队完成持久化返回ACK告知投递成功其它情况都会返回NACK告知投递失败实现发送者确认1、在publisher这个微服务的application.yml中添加配置publisher-confirm-type三种模式选择none关闭confirm机制默认simple同步阻塞等待MQ的回执消息correlatedMQ异步回调方式返回回执消息2、每个RabbitTemplate只能配置一个ReturnCallback因此需要在项目启动过程中配置3、发送消息指定ID、消息ConfirmCallbackMQ可靠性-数据持久化在默认情况下RabbitMQ会将接收到的信息保存在内存中以降低消息收发的延迟导致两个问题一旦MQ宕机内存中的消息会丢失内存空间有限当消费者故障过处理过慢时会导致消息积压引发MQ阻塞RabbitMQ实现数据持久化包括三个方面交换机持久化队列持久化消息持久化MQ可靠性-Lazy Queue从RabbitMQ的3.6.0版本开始增加了Lazy Queue的概念也就是惰性队列惰性队列特征接收到消息后直接存入磁盘不再存储到内存消费者要消费消息时才会从磁盘中读取并加载到内存可以提前缓存1部分消息到内存最多2048条在3.12版本后所有队列都是Lazy Queue模式无法更改要设置一个队列为惰性队列只需要在声明队列时指定x-queue-mode属性为lazy即可控制台添加代码添加注解添加RabbitMQ如何保证消息的可靠性首先通过配置让交换机、队列、以及发送的消息都持久化。这样队列中的消息会持久化到磁盘MQ重启消息依然存在RabbitMQ在3.6版本引入LazyQueue并且3.12版本后会称为队列的默认模式LayQueue会将所有消息都持久化开启持久化和生产者确认时RabbitMQ只有在消息持久化成功后才会给生产者返回ACK回执消费者可靠性-消费者确认消费者确认机制是为了确认消费者是否成功处理消息。当消费者处理消息结束后应该向RabbitMQ发送应一个回执告知RabbitMQ自己消息处理状态ack成功处理消息RabbitMQ从队列中删除该消息nack消息处理失败RabbitMQ需要再次投递消息reject消息处理失败并拒绝该消息RabbitMQ从队列中删除该消息SpringAMQP已经实现了消息确认功能。并允许我们通过配置文件选择ACK处理方式none不处理。消息投递给消费者后立刻ack消息会立即从MQ删除。不建议使用manual手动模式。需要自己在业务代码中调用api发送ack或reject存在业务侵入但更灵活auto自动模式。SpringAMQP利用AOP对我们的消息处理逻辑做了环绕增强当业务正常执行时则自动返回ack——当业务出现异常根据异常判断返回不同结果1、如果是业务异常会自动返回nack2、如果是消息处理或校验异常自动返回reject消费者可靠性-失败重试SpringAMQP提供了消费者失败重试机制在消费者出现异常时利用本地重试而不是无限的requeue到mq可以通过application.yaml文件中添加配置来开启重试机制失败消息处理策略在开启重试模式后重试次数耗尽如果消息依然失败则需要有MessageRecoverer接口来处理它包含三种不同的实现RejectAndDontRequeueRecoverer重试耗尽后直接reject丢弃消息。默认ImmediateRequeueMessageRecoverer重试耗尽后返回nack消息重新入队RepublishMessageRecoverer重试耗尽后将失败消息投递到指定的交换机失败消息策略实现:1、定义接收失败消息的交换机、队列及其绑定关系2、定义RepublishMessageRecoverer3、开启消费者失败重试机制消费者可靠性-业务幂等性幂等是一个数学概念用函数表达式来描述fx ffx程序开发中则是指同一个业务执行一次或多次对业务状态的影响是一致的唯一消息id方案一给每个消息都设置一个唯一id利用id区分是否重复消息1、每一条消息都生成一个唯一的id与消息一起投递给消费者2、消费者接收到消息后处理自己的业务业务处理成功后将消息ID保存到数据库3、如果下次又收到相同消息去数据库查询判断是否存在存在则为重复消息放弃处理方案二结合业务逻辑基于业务本身做判断如何保证支付服务与交易服务之间的订单状态一致性1、首先支付服务会在用户支付成功以后利用MQ消息通知交易服务完成订单状态同步2、其次为了保证MQ消息可靠性采用生产者确认机制、消费者确认机制、消费者失败重试等策略确保消息投递和处理的可靠。同时开启MQ的持久化,避免因服务宕机导致消息丢失3、最后,在交易服务更新订单状态时做业务幂等判断,避免因消息重复消费导致订单状态异常