生产者的可靠
首先，我们一起分析一下消息丢失的可能性有哪些。
消息从发送者发送消息，到消费者处理消息，需要经过的流程是这样的：
消息从生产者到消费者的每一步都可能导致消息丢失：
● 发送消息时丢失：
○ 生产者发送消息时连接MQ失败
○ 生产者发送消息到达MQ后未找到Exchange
○ 生产者发送消息到达MQ的Exchange后，未找到合适的Queue
○ 消息到达MQ后，处理消息的进程发生异常
● MQ导致消息丢失：
○ 消息到达MQ，保存到队列后，尚未消费就突然宕机
● 消费者处理消息时：
○ 消息接收后尚未处理突然宕机
○ 消息接收后处理过程中抛出异常
综上，我们要解决消息丢失问题，保证MQ的可靠性，就必须从3个方面入手：
● 确保生产者一定把消息发送到MQ
● 确保MQ不会将消息弄丢
● 确保消费者一定要处理消息
这一章我们先来看如何确保生产者一定能把消息发送到MQ。
生产者重试机制
首先第一种情况，就是生产者发送消息时，出现了网络故障，导致与MQ的连接中断。
为了解决这个问题，SpringAMQP提供的消息发送时的重试机制。即：当RabbitTemplate与MQ连接超时后，多次重试。
我在我的 生产者工程里面的 application.yml 中新增以下配置：
spring:rabbitmq:connection-timeout: 1s # 设置MQ的连接超时时间template:retry:enabled: true # 开启超时重试机制initial-interval: 1000ms # 失败后的初始等待时间multiplier: 1 # 失败后下次的等待时长倍数，下次等待时长 = 失败后的初始等待时间（initial-interval） * multipliermax-attempts: 4 # 最大重试次数
然后我停掉了 我的 mq服务
docker atop mq
然后找一个之前就写好的测试类，发送消息测试下。会发现会每隔1秒（连接超时1秒，隔1秒；所以输出的时候显示每隔2秒）重试1次，总共重试了4次。消息发送的超时重试机制配置成功了！
注意：当网络不稳定的时候，利用重试机制可以有效提高消息发送的成功率。不过SpringAMQP提供的重试机制是阻塞式的重试，也就是说多次重试等待的过程中，当前线程是被阻塞的。
如果对于业务性能有要求，建议禁用重试机制。如果一定要使用，请合理配置等待时长和重试次数，当然也可以考虑使用异步线程来执行发送消息的代码。
生产者确认机制
一般情况下，只要生产者与MQ之间的网路连接顺畅，基本不会出现发送消息丢失的情况，因此大多数情况下我们无需考虑这种问题。
不过，在少数情况下，也会出现消息发送到MQ之后丢失的现象，比如：
● MQ内部处理消息的进程发生了异常
● 生产者发送消息到达MQ后未找到Exchange
● 生产者发送消息到达MQ的Exchange后，未找到合适的Queue，因此无法路由
针对上述情况，RabbitMQ提供了生产者消息确认机制，包括Publisher Confirm和Publisher Return两种。在开启确认机制的情况下，当生产者发送消息给MQ后，MQ会根据消息处理的情况返回不同的回执。
具体如图所示：
总结如下：
● 当消息投递到MQ，但是路由失败时，通过Publisher Return返回异常信息，同时返回ack的确认信息，代表投递成功
● 临时消息投递到了MQ，并且入队成功，返回ACK，告知投递成功
● 持久消息投递到了MQ，并且入队完成持久化，返回ACK ，告知投递成功
● 其它情况都会返回NACK，告知投递失败
其中ack和nack属于Publisher Confirm机制，ack是投递成功；nack是投递失败。而return则属于Publisher Return机制。
默认两种机制都是关闭状态，需要通过配置文件来开启。
实现生产者确认机制
开启生产者确认
我在我的 publisher工程中的application.yml 中添加以下配置：
spring:rabbitmq:publisher-confirm-type: correlated # 开启publisher confirm机制，并设置confirm类型publisher-returns: true # 开启publisher return机制
定义ReturnCallback
每个RabbitTemplate只能配置一个ReturnCallback，因此我们可以在配置类中统一设置。我们在publisher模块定义一个配置类。
我在我的publisher工程中的config包里面，创建MqConfig类。编写以下代码
@Slf4j
@Configuration
@RequiredArgsConstructor
public class MqConfig {private final RabbitTemplate rabbitTemplate;@PostConstructpublic void init() {rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {@Overridepublic void returnedMessage(ReturnedMessage returned) {log.debug("触发了 return callback！");log.info("exchange = {}",returned.getExchange());log.info("routingKey = {}",returned.getRoutingKey());log.info("message = {}",returned.getMessage());log.info("replyText = {}",returned.getReplyText());log.info("replyCode = {}",returned.getReplyCode());}});}
}
定义ConfirmCallback
由于每个消息发送时的处理逻辑不一定相同，因此ConfirmCallback需要在每次发消息时定义。具体来说，是在调用RabbitTemplate中的convertAndSend方法时，多传递一个参数：
这里的CorrelationData中包含两个核心的东西：
● id：消息的唯一标示，MQ对不同的消息的回执以此做判断，避免混淆
● SettableListenableFuture：回执结果的Future对象
将来MQ的回执就会通过这个Future来返回，我们可以提前给CorrelationData中的Future添加回调函数来处理消息回执：
我们新增一个测试方法，向交换机发送消息并且routing key是不存在的来进行测试，并且添加ConfirmCallback：
在测试类里面编写一个 testConfirmCallback 方法
@Test@DisplayName("定义一个ConfirmCallback方法")public void testConfirmCallback() throws InterruptedException {//创建CorrelationData对象CorrelationData cd = new CorrelationData();cd.getFuture().addCallback(new ListenableFutureCallback<CorrelationData.Confirm>() {@Overridepublic void onFailure(Throwable ex) {//只有当future 发生异常时，才会回调 onFailure方法，基本不会发生log.error("消息发送失败！onFailure{}",ex.getMessage());}@Overridepublic void onSuccess(CorrelationData.Confirm result) {//当Future无异常成功时，才会回调onSuccess方法；接收到回执的处理逻辑；result是回执内容if (result.isAck()){log.info("消息发送成功！onSuccess：接收到回执ack");}else {log.info("消息发送失败！onSuccess：接收到回执nack，失败原因：{}",result.getReason());}}});//交换机String exchangeName = "test.direct";//消息String msg = "hello word";//发送消息 发送的交换机存在，但是路由key是不存在的rabbitTemplate.convertAndSend(exchangeName,"aaa",msg,cd);//线程休眠3秒，等消息发送成功并接收到回执等信息Thread.sleep(3000);}运行这个测试类看看错误日志
可以看到，由于传递的RoutingKey是错误的，路由失败后，触发了return callback，同时也收到了ack。
当我们修改为正确的RoutingKey以后，就不会触发return callback了，只收到ack。
而如果连交换机都是错误的，则只会收到nack。
Tips：
开启生产者确认比较消耗MQ性能，一般不建议开启。而且大家思考一下触发确认的几种情况：
- 路由失败：一般是因为RoutingKey错误导致，往往是编程导致
- 交换机名称错误：同样是编程错误导致
- MQ内部故障：这种需要处理，但概率往往较低。因此只有对消息可靠性要求非常高的业务才需要开启，而且仅仅需要开启ConfirmCallback处理nack就可以了。
MQ的可靠性
消息到达MQ以后，如果MQ不能及时保存，也会导致消息丢失，所以MQ的可靠性也非常重要。
数据持久化
为了提升性能，默认情况下MQ的数据都是在内存存储的临时数据，重启后就会消失。为了保证数据的可靠性，必须配置数据持久化，包括：
● 交换机持久化
● 队列持久化
● 消息持久化
我们以控制台界面为例来说明。
交换机持久化
在控制台的Exchanges页面，添加交换机时可以配置交换机的Durability参数：
设置为Durable就是持久化模式，Transient就是临时模式。
测试： 可以创建一个名 test1 的交换机；然后设置为 Transient ，再重启 mq 之后查看；它已经不存在，说明它是临时的，重启之后就不存在。
创建成功后
重启docker测试
docker restart mq
可以看到刚刚创建的test1交换机就不存在了
队列持久化
在控制台的Queues页面，添加队列时，同样可以配置队列的Durability参数：
除了持久化以外，你可以看到队列还有很多其它参数，有一些我们会在后期学习。
测试：可以创建一个名 test1 的队列；然后设置为 Transient ，再重启 mq 之后查看；它已经不存在，说明它是临时的，重启之后就不存在。
添加test1队列后
重启mq
docker restart mq
重启后
重启之后；上面名字为 test 的队列将不存在。
消息持久化
在控制台发送消息的时候，可以添加很多参数，而消息的持久化是要配置一个Delivery mode：
测试：在 simple.queue 下发两条消息；一条是持久化的，一条是临时的消息；然后重启mq再查看队列中的消息。
重启mq之前
重启mq
docker restart mq
重启之后在看下消息
说明：
1、持久化的消息：是在没有消费的情况下存在MQ，消费了的话也被删除
2、在开启持久化机制以后，如果同时还开启了生产者确认，那么MQ会在消息持久化以后才发送ACK回执，进一步确保消息的可靠性。
不过出于性能考虑，为了减少IO次数，发送到MQ的消息并不是逐条持久化到数据库的，而是每隔一段时间批量持久化。一般间隔在100毫秒左右，这就会导致ACK有一定的延迟，因此建议生产者确认全部采用异步方式。
LazyQueue
在默认情况下，RabbitMQ会将接收到的信息保存在内存中以降低消息收发的延迟。但在某些特殊情况下，这会导致消息积压，比如：
● 消费者宕机或出现网络故障
● 消息发送量激增，超过了消费者处理速度
● 消费者处理业务发生阻塞
一旦出现消息堆积问题，RabbitMQ的内存占用就会越来越高，直到触发内存预警上限。此时RabbitMQ会将内存消息刷到磁盘上，这个行为称为PageOut. PageOut会耗费一段时间，并且会阻塞队列进程。因此在这个过程中RabbitMQ不会再处理新的消息，生产者的所有请求都会被阻塞。
我们新写一个测试类，testPageOut() 演示 PageOut 向simple.queue 队列中发送100w条消息
为了更好的看到测试效果，我们关闭 publisher工程的 的消息确认机制
spring:rabbitmq:publisher-confirm-type: nonepublisher-returns: false
测试的代码
@Test@DisplayName("发送100w条消息")public void testPageOut(){//队列名称String queueName = "test";//消息Message message = MessageBuilder.withBody("hello".getBytes(StandardCharsets.UTF_8)).setDeliveryMode(MessageDeliveryMode.NON_PERSISTENT).build();//发消息for (int i = 0; i < 1000000; i++) {rabbitTemplate.convertAndSend(queueName,message);}}
看效果
在控制台中将队列消息清空；
再修改上述代码；发送持久化消息测试结果如下：
@Test@DisplayName("发送100w条消息")public void testPageOut(){//队列名称String queueName = "test";//消息Message message = MessageBuilder.withBody("hello".getBytes(StandardCharsets.UTF_8)).setDeliveryMode(MessageDeliveryMode.PERSISTENT).build();//发消息for (int i = 0; i < 1000000; i++) {rabbitTemplate.convertAndSend(queueName,message);}}
看效果
为了解决这个问题，从RabbitMQ的3.6.0版本开始，就增加了Lazy Queue的模式，也就是惰性队列。惰性队列的特征如下：
- 接收到消息后直接存入磁盘而非内存
- 消费者要消费消息时才会从磁盘中读取并加载到内存（也就是懒加载）
- 支持数百万条的消息存储
而在3.12版本之后，LazyQueue已经成为所有队列的默认格式。因此官方推荐升级MQ为3.12版本或者所有队列都设置为LazyQueue模式。
控制台配置 Lazy 模式
在添加队列的时候，添加x-queue-mod=lazy参数即可设置队列为Lazy模式：
测试效果；再修改上述代码；发送非持久化消息到 lazy.queue 测试结果如下：
@Test@DisplayName("发送100w条消息")public void testPageOut(){//队列名称String queueName = "lazy.queue";//消息Message message = MessageBuilder.withBody("hello".getBytes(StandardCharsets.UTF_8)).setDeliveryMode(MessageDeliveryMode.NON_PERSISTENT).build();//发消息for (int i = 0; i < 1000000; i++) {rabbitTemplate.convertAndSend(queueName,message);}}
看效果
代码配置Lazy模式（了解）
下面的内容；只是展示如何使用代码方式设置队列为lazy；效果与控制配置一样，不再测试；所以也就不需要再写任何代码了。大家了解即可。
在利用SpringAMQP声明队列的时候，添加x-queue-mod=lazy参数也可设置队列为Lazy模式：
@Slf4j
@Component
public class LazyQueueConfig {@Beanpublic Queue lazyQueue(){return QueueBuilder.durable("lazy.queue2").lazy() // 消息队列是否是lazy模式；里面设置了一个参数x-queue-mode，表示是否是lazy模式.build();}
}
当然，我们也可以基于注解来声明队列并设置为Lazy模式：
@Slf4j
@Configuration
public class NoteLazyQueue {@RabbitListener(queuesToDeclare = @Queue(value = "lazy.queue3",durable = "true",arguments = @Argument(name = "x-queue-mode",value = "lazy")))public void listenLazyQueue(String msg){log.info("消费者接收到 lazy.queue 队列的消息：{}",msg);}
}
看效果
消费者的可靠性
当RabbitMQ向消费者投递消息以后，需要知道消费者的处理状态如何。因为消息投递给消费者并不代表就一定被正确消费了，可能出现的故障有很多，比如：
- 消息投递的过程中出现了网络故障
- 消费者接收到消息后突然宕机
- 消费者接收到消息后，因处理不当导致异常
- ...
一旦发生上述情况，消息也会丢失。因此，RabbitMQ必须知道消费者的处理状态，一旦消息处理失败才能重新投递消息。
但问题来了：RabbitMQ如何得知消费者的处理状态呢？
本章我们就一起研究一下消费者处理消息时的可靠性解决方案。
消费者确认机制
为了确认消费者是否成功处理消息，RabbitMQ提供了消费者确认机制（Consumer Acknowledgement）。即：当消费者处理消息结束后，应该向RabbitMQ发送一个回执，告知RabbitMQ自己消息处理状态。回执有三种可选值：
● ack：成功处理消息，RabbitMQ从队列中删除该消息
● nack：消息处理失败，RabbitMQ需要再次投递消息
● reject：消息处理失败并拒绝该消息，RabbitMQ从队列中删除该消息
一般reject方式用的较少，除非是消息格式有问题，那就是开发问题了。因此大多数情况下我们需要将消息处理的代码通过try catch机制捕获，消息处理成功时返回ack，处理失败时返回nack.
由于消息回执的处理代码比较统一，因此SpringAMQP帮我们实现了消息确认。并允许我们通过配置文件设置ACK处理方式，有三种模式：
● none：不处理。即消息投递给消费者后立刻ack，消息会立刻从MQ删除。非常不安全，不建议使用
● manual：手动模式。需要自己在业务代码中调用api，发送ack或reject，存在业务入侵，但更灵活
● auto：自动模式。SpringAMQP利用AOP对我们的消息处理逻辑做了环绕增强，当业务正常执行时则自动返回ack. 当业务出现异常时，根据异常判断返回不同结果：
○ 如果是业务异常，会自动返回nack；
○ 如果是消息处理或校验异常，自动返回reject;
返回Reject的常见异常有：
Starting with version 1.3.2, the default ErrorHandler is now a ConditionalRejectingErrorHandler that rejects (and does not requeue) messages that fail with an irrecoverable error. Specifically, it rejects messages that fail with the following errors:
● o.s.amqp…MessageConversionException: Can be thrown when converting the incoming message payload using a MessageConverter.
● o.s.messaging…MessageConversionException: Can be thrown by the conversion service if additional conversion is required when mapping to a @RabbitListener method.
● o.s.messaging…MethodArgumentNotValidException: Can be thrown if validation (for example, @Valid) is used in the listener and the validation fails.
● o.s.messaging…MethodArgumentTypeMismatchException: Can be thrown if the inbound message was converted to a type that is not correct for the target method. For example, the parameter is declared as Message<Foo> but Message<Bar> is received.
● java.lang.NoSuchMethodException: Added in version 1.6.3.
● java.lang.ClassCastException: Added in version 1.6.3.
通过下面的配置可以修改SpringAMQP的ACK处理方式；需要注意的是在消费方的配置文件中新增如下配置：
修改consumer工程中的配置
spring:rabbitmq:listener:simple:acknowledge-mode: none # 不做处理
修改consumer服务的SpringRabbitListener类中的方法，模拟一个消息处理的异常：
@RabbitListener(queues = "simple.queue")public void listenerSimpleQueue(String msg){log.info("消费者接收到 simple.queue 队列的消息：{}",msg);//故意抛出消息转换异常 - rejectthrow new MessageConversionException("故意抛出的消息转换异常");}
看看 simple.queue 队列中是否还有消息
测试：在代码中往 simple.queue队列发送消息，执行 testSendMessage() 方法； 发送消息。
可以发现：当消息处理发生异常时，消息依然被RabbitMQ删除了。
我们再次把确认机制修改为auto：
spring:rabbitmq:listener:simple:acknowledge-mode: auto # 自动ack
在异常位置打断点，再次发送消息，程序卡在断点时，可以发现此时消息状态为unacked（未确定状态）：
记得要 deBug启动项目
看看mq控制台
放行以后，由于抛出的是消息转换异常，因此Spring会自动返回reject，所以消息依然会被删除：
我们将异常改为RuntimeException类型：
放行后
在异常位置打断点，然后再次发送消息测试，程序卡在断点时，可以发现此时消息状态为unacked（未确定状态）：
放行以后，由于抛出的是业务异常，所以Spring返回ack，最终消息恢复至Ready状态，并且没有被RabbitMQ删除；会一直投递，可以关闭consumer后再看控制台：
当我们把配置改为auto时，消息处理失败后，会回到RabbitMQ，并重新投递到消费者。
失败重试机制
当消费者出现异常后，消息会不断requeue（重入队）到队列，再重新发送给消费者。如果消费者再次执行依然出错，消息会再次requeue到队列，再次投递，直到消息处理成功为止。
极端情况就是消费者一直无法执行成功，那么消息requeue就会无限循环，导致mq的消息处理飙升，带来不必要的压力：
当然，上述极端情况发生的概率还是非常低的，不过不怕一万就怕万一。为了应对上述情况Spring又提供了消费者失败重试机制：在消费者出现异常时利用本地重试，而不是无限制的requeue到mq队列。
修改consumer服务的application.yml文件，添加内容：
spring:rabbitmq:listener:simple:retry:enabled: truemax-attempts: 3 # 最大重试次数initial-interval: 1000 # 重试间隔时间multiplier: 1 # 重试间隔时间倍数；下次等待时长 = 上次重试间隔时间（initial-interval） * multiplierstateless: true # 是否为无状态的，即重试时会重新获取一次连接；如果包含事务则为 false
重启consumer服务，重复之前的测试。可以发现：
● 消费者在失败后消息没有重新回到MQ无限重新投递，而是在本地重试了3次
● 本地重试3次以后，抛出了AmqpRejectAndDontRequeueException异常。查看RabbitMQ控制台，发现消息被删除了，说明最后SpringAMQP返回的是reject
结论：
● 开启本地重试时，消息处理过程中抛出异常，不会requeue到队列，而是在消费者本地重试
● 重试达到最大次数后，Spring会返回reject，消息会被丢弃
可以发现这一次我就重试了3次，断点就结束了。
失败处理策略
在之前的测试中，本地测试达到最大重试次数后，消息会被丢弃。这在某些对于消息可靠性要求较高的业务场景下，显然不太合适了。
因此Spring允许我们自定义重试次数耗尽后的消息处理策略，这个策略是由MessageRecovery接口来定义的，它有3个不同实现：
- RejectAndDontRequeueRecoverer：重试耗尽后，直接reject，丢弃消息。默认就是这种方式
- ImmediateRequeueMessageRecoverer：重试耗尽后，返回nack，消息重新入队
- RepublishMessageRecoverer：重试耗尽后，将失败消息投递到指定的交换机
比较优雅的一种处理方案是RepublishMessageRecoverer，失败后将消息投递到一个指定的，专门存放异常消息的队列，后续由人工集中处理。
采用第三种方式的话：在消费者方创建 ErrorMessageConfig 代码如下：
@Configuration
public class ErrorMessageConfig {/*** 定义名字为 error.direct 的队列* @return*/@Beanpublic Queue errorQueue(){return new Queue("error.queue");}/*** 定义名字为 error.exchange 的交换机* @return*/@Beanpublic DirectExchange errorExchange() {return new DirectExchange("error.exchange", true, false);}/*** 绑定队列到交换机* @param errorQueue* @param errorExchange* @return*/@Beanpublic Binding errorBinding(Queue errorQueue, DirectExchange errorExchange){return BindingBuilder.bind(errorQueue).to(errorExchange).with("error");}/*** 设置RabbitTemplate在尝试接收最大次数之后投递的交换机和路由key* @param rabbitTemplate* @return*/@Beanpublic MessageRecoverer messageRecoverer(RabbitTemplate rabbitTemplate){return new RepublishMessageRecoverer(rabbitTemplate,"error.exchange","error");}
}测试：启动consumer；然后再次发送消息到 simple.queue 可以看到在 error.queue队列中有消息及异常信息。
可以看到完整的异常信息了
业务幂等性
何为幂等性？
幂等是一个数学概念，用函数表达式来描述是这样的：f(x) = f(f(x))，例如求绝对值函数。
在程序开发中，则是指同一个业务，执行一次或多次对业务状态的影响是一致的。例如：
- 根据id删除数据
- 查询数据
- 新增数据
但数据的更新往往不是幂等的，如果重复执行可能造成不一样的后果。比如：
- 取消订单，恢复库存的业务。如果多次恢复就会出现库存重复增加的情况
- 退款业务。重复退款对商家而言会有经济损失。
所以，我们要尽可能避免业务被重复执行。
然而在实际业务场景中，由于意外经常会出现业务被重复执行的情况，例如：
- 页面卡顿时频繁刷新导致表单重复提交
- 服务间调用的重试
- MQ消息的重复投递
我们在用户支付成功后会发送MQ消息到交易服务，修改订单状态为已支付，就可能出现消息重复投递的情况。如果消费者不做判断，很有可能导致消息被消费多次，出现业务故障。
举例：
- 假如用户刚刚支付完成，并且投递消息到交易服务，交易服务更改订单为已支付状态。
- 由于某种原因，例如网络故障导致生产者没有得到确认，隔了一段时间后重新投递给交易服务。
- 但是，在新投递的消息被消费之前，用户选择了退款，将订单状态改为了已退款状态。
- 退款完成后，新投递的消息才被消费，那么订单状态会被再次改为已支付。业务异常。
因此，我们必须想办法保证消息处理的幂等性。这里给出两种方案：
- 唯一消息ID
- 业务状态判断
唯一消息ID
这个思路非常简单：
1. 每一条消息都生成一个唯一的id，与消息一起投递给消费者。
2. 消费者接收到消息后处理自己的业务，业务处理成功后将消息ID保存到数据库
3. 如果下次又收到相同消息，去数据库查询判断是否存在，存在则为重复消息放弃处理。
我们该如何给消息添加唯一ID呢？
其实很简单，SpringAMQP的MessageConverter自带了MessageID的功能，我们只要开启这个功能即可。
以Jackson的消息转换器为例：
@Bean
public MessageConverter messageConverter() {//1、定义消息转换器Jackson2JsonMessageConverter jackson2JsonMessageConverter = new Jackson2JsonMessageConverter();//2、配置每条消息自动创建id；用于识别不同消息，也可以在页面中基于id判断是否是重复消息jackson2JsonMessageConverter.setCreateMessageIds(true);return jackson2JsonMessageConverter;
}测试：在代码中任意发一条消息；然后在控制台都能够查看到消息的ID。
业务判断
业务判断就是基于业务本身的逻辑或状态来判断是否是重复的请求或消息，不同的业务场景判断的思路也不一样。
例如我们当前案例中，处理消息的业务逻辑是把订单状态从未支付修改为已支付。因此我们就可以在执行业务时判断订单状态是否是未支付，如果不是则证明订单已经被处理过，无需重复处理。
相比较而言，消息ID的方案需要改造原有的数据库，所以更推荐使用业务判断的方案。
public void markOrderPaySuccess(Long orderId) {//查找订单Order old = getById(orderId);//判断订单状态if (old == null || old.getStatus() != 1) {//订单不存在或订单状态不为1（待支付）；放弃更新状态return;}//修改订单状态Order order = new Order();order.setId(orderId);order.setStatus(2);order.setPayTime(LocalDateTime.now());updateById(order);
}上述代码逻辑上符合了幂等判断的需求，但是由于判断和更新是两步动作，因此在极小概率下可能存在线程安全问题。
我们可以合并上述操作为这样：
public void markOrderPaySuccess(Long orderId) {// update `order` set `status` = 2, `pay_time` = now() where `id` = orderId and `status` = 1;lambdaUpdate().set(Order::getStatus, 2).set(Order::getPayTime, LocalDateTime.now()).eq(Order::getId, orderId).eq(Order::getStatus, 1).update();
}我们在where条件中除了判断id以外，还加上了status必须为1的条件。如果条件不符（说明订单已支付），则SQL匹配不到数据，根本不会执行。
兜底方案
虽然我们利用各种机制尽可能增加了消息的可靠性，但也不好说能保证消息100%的可靠。万一真的MQ通知失败该怎么办呢？
● 接收MQ的消息是被动接收
● 兜底方案可以主动去查
比如：在订单支付状态的更新；有没有其它兜底方案，能够确保订单的支付状态一致呢？
其实思想很简单：既然MQ通知不一定发送到交易服务，那么交易服务就必须自己主动去查询支付状态。这样即便支付服务的MQ通知失败，我们依然能通过主动查询来保证订单状态的一致。
流程如下：
图中黄色线圈起来的部分就是MQ通知失败后的兜底处理方案，由交易服务自己主动去查询支付状态。
不过需要注意的是，交易服务并不知道用户会在什么时候支付，如果查询的时机不正确（比如查询的时候用户正在支付中），可能查询到的支付状态也不正确。
那么问题来了，我们到底该在什么时间主动查询支付状态呢？
这个时间是无法确定的，因此，通常我们采取的措施就是利用定时任务定期查询，例如每隔20秒就查询一次，并判断支付状态。如果发现订单已经支付，则立刻更新订单状态为已支付即可。
定时任务大家之前学习过，具体的实现这里就不再赘述了。
至此，消息可靠性的问题已经解决了。
综上，支付服务与交易服务之间的订单状态一致性是如何保证的？
● 首先，支付服务会正在用户支付成功以后利用MQ消息通知交易服务，完成订单状态同步。
● 其次，为了保证MQ消息的可靠性，我们采用了生产者确认机制、消费者确认、消费者失败重试等策略，确保消息投递的可靠性
● 最后，我们还在交易服务设置了定时任务，定期查询订单支付状态。这样即便MQ通知失败，还可以利用定时任务作为兜底方案，确保订单支付状态的最终一致性。
延迟消息
在电商的支付业务中，对于一些库存有限的商品，为了更好的用户体验，通常都会在用户下单时立刻扣减商品库存。例如电影院购票、高铁购票，下单后就会锁定座位资源，其他人无法重复购买。
但是这样就存在一个问题，假如用户下单后一直不付款，就会一直占有库存资源，导致其他客户无法正常交易，最终导致商户利益受损！
因此，电商中通常的做法就是：对于超过一定时间未支付的订单，应该立刻取消订单并释放占用的库存。
例如，订单支付超时时间为30分钟，则我们应该在用户下单后的第30分钟检查订单支付状态，如果发现未支付，应该立刻取消订单，释放库存。
但问题来了：如何才能准确的实现在下单后第30分钟去检查支付状态呢？
像这种在一段时间以后才执行的任务，我们称之为延迟任务，而要实现延迟任务，最简单的方案就是利用MQ的延迟消息了。
延迟消息：生产者发送消息时指定一个时间，消费者不会立刻收到消息，而是在指定时间之后才收到消息。
在RabbitMQ中实现延迟消息也有两种方案：
● 死信交换机+TTL
● 延迟消息插件
死信交换机
先来看看什么是死信交换机
死信交换机
什么是死信？
当一个队列中的消息满足下列情况之一时，可以成为死信（dead letter）：
● 消费者使用basic.reject或 basic.nack声明消费失败，并且消息的requeue参数设置为false
● 消息是一个过期消息，超时无人消费
● 要投递的队列消息满了，无法投递
如果一个队列中的消息已经成为死信，并且这个队列通过dead-letter-exchange属性指定了一个交换机，那么队列中的死信就会投递到这个交换机中，而这个交换机就称为死信交换机（Dead Letter Exchange）。而此时加入有队列与死信交换机绑定，则最终死信就会被投递到这个队列中。
在控制台中演示上述图效果：
创建 dlx.queue 队列，并设置 x-dead-letter-exchange 为 dlx.direct
创建普通队列 dlx.queue
创建 simple.direct 交换机并绑定 simple.queue2
类似上述方式；创建 dlx.direct 交换机并绑定 dlx.queue
在 com.itheima.publisher.amqp.SpringAmqpTest 编写发送消息到 simple.direct 的代码：
/*** 发送过期消息到 simple.direct 交换机*/
@Test
public void testSendExpiredMessage() {// 发送 10s 过期消息System.out.println("发送时间：" + LocalTime.now());rabbitTemplate.convertAndSend("simple.direct", "", "hello delay message. ", new MessagePostProcessor() {@Overridepublic Message postProcessMessage(Message message) throws AmqpException {message.getMessageProperties().setExpiration("10000");return message;}});
}
在消费者编写代码监听 dlx.queue 队列
@Slf4j
@Component
public class DlxQueueListener {@RabbitListener(queues = "dlx.queue")public void listenerDlxQueue(String msg) {log.info("dlx.queue监听到消息：{}", msg);}
}
死信交换机有什么作用呢？
- 收集那些因处理失败而被拒绝的消息
- 收集那些因队列满了而被拒绝的消息
- 收集因TTL（有效期）到期的消息
携带RoutingKey（了解）
前面两种作用场景可以看做是把死信交换机当做一种消息处理的最终兜底方案，与消费者重试时讲的RepublishMessageRecoverer作用类似。
如果有携带Routingkey的延迟消息；可以了解如下图示（课上不再演示）：
如图，有一组绑定的交换机（ttl.fanout）和队列（ttl.queue）。但是ttl.queue没有消费者监听，而是设定了死信交换机hmall.direct，而队列direct.queue1则与死信交换机绑定，RoutingKey是blue：
假如我们现在发送一条消息到ttl.fanout，RoutingKey为blue，并设置消息的有效期为5000毫秒：
注意：尽管这里的ttl.fanout不需要RoutingKey，但是当消息变为死信并投递到死信交换机时，会沿用之前的RoutingKey，这样hmall.direct才能正确路由消息。
消息肯定会被投递到ttl.queue之后，由于没有消费者，因此消息无人消费。5秒之后，消息的有效期到期，成为死信：
死信被再次投递到死信交换机hmall.direct，并沿用之前的RoutingKey，也就是blue：
由于direct.queue1与hmall.direct绑定的key是blue，因此最终消息被成功路由到direct.queue1，如果此时有消费者与direct.queue1绑定， 也就能成功消费消息了。但此时已经是5秒钟以后了：
也就是说，publisher发送了一条消息，但最终consumer在5秒后才收到消息。我们成功实现了延迟消息。
注意：
RabbitMQ的消息过期是基于追溯方式来实现的，也就是说当一个消息的TTL到期以后不一定会被移除或投递到死信交换机，而是在消息恰好处于队首时才会被处理。
当队列中消息堆积很多的时候，过期消息可能不会被按时处理，因此你设置的TTL时间不一定准确。
延迟消息插件
基于死信队列虽然可以实现延迟消息，但是太麻烦了。因此RabbitMQ社区提供了一个延迟消息插件来实现相同的效果。
官方文档说明：Scheduling Messages with RabbitMQ | RabbitMQ
下载
插件下载地址：
Tags · rabbitmq/rabbitmq-delayed-message-exchange · GitHub
由于我们安装的MQ是3.8版本，因此这里下载3.8.17版本：
当然，也可以直接使用资料提供好的插件；我已经下载好的/rabbitmq_delayed_message_exchange-3.8.17.8f537ac.ez
安装
因为我们是基于Docker安装，所以需要先查看RabbitMQ的插件目录对应的数据卷。
docker volume ls
docker volume inspect mq-plugins
插件目录被挂载到了/var/lib/docker/volumes/mq-plugins/_data这个目录，我们上传插件到该目录下。
cd /var/lib/docker/volumes/mq-plugins/_data
接下来进入mq容器执行命令，安装插件：
docker exec -it mq rabbitmq-plugins enable rabbitmq_delayed_message_exchange
执行上述命令后再重启mq容器；结果如下：
docker restart mq
声明延迟交换机
1）基于注解方式；并接收消息
新写一个方法
@RabbitListener(bindings = @QueueBinding(value = @Queue(value = "delay.queue",durable = "true"),exchange = @Exchange(value = "delay.direct",delayed = "true"),key = "delay"))public void listenDelayQueueMessage(String msg){log.info("消费者接收到 delay.queue 队列的消息：{}",msg);}
2）基于 @Bean方式声明
我先提前把根据上面注解创建的 交换机和队列删除了
@Slf4j
@Component
public class DelayExchangeConfig {@Beanpublic DirectExchange delayDelayExchange(){return ExchangeBuilder.directExchange("delay.direct").delayed().durable(true).build();}@Beanpublic Queue delayQueue(){return new Queue("delay.queue");}@Beanpublic Binding delayBinding(Queue delayQueue, DirectExchange delayDelayExchange){return BindingBuilder.bind(delayQueue).to(delayDelayExchange).with("delay");}}启动consumer工程，查看mq控制台。
发送延迟消息
在测试类中编写代码
@Slf4j
@SpringBootTest
public class DelayMessageTest {@Autowiredprivate RabbitTemplate rabbitTemplate;@Test@DisplayName("发送延时消息")public void testDelayMessage() {//发送 5s 过期System.out.println("发送时间：" + LocalDateTime.now());//交换机String exchangeName = "delay.direct";//消息String message = "延时消息";rabbitTemplate.convertAndSend(exchangeName, "delay", message, new MessagePostProcessor() {@Overridepublic Message postProcessMessage(Message message) throws AmqpException {message.getMessageProperties().setDelay(5000); //5秒过期return message;}});}
}
5秒之前
5秒之后
注意：
延迟消息插件内部会维护一个本地数据库表，同时使用Elang Timers功能实现计时。如果消息的延迟时间设置较长，可能会导致堆积的延迟消息非常多，会带来较大的CPU开销，同时延迟消息的时间会存在误差。
因此，不建议设置延迟时间过长的延迟消息。