RabbitMQ延时队列

1、场景：

比如未付款订单，超过一定时间后，系统自动取消订单，并释放占用物品

2、上述场景的解决方案：

1)spring schedule的定时任务轮询数据库

缺点：消耗系统内存，增加数据库压力，存在较大的时间误差

(例如如果订单30分钟未支付时取消订单，且定时任务30分钟执行一次，那么一个订单最晚会59分钟才会被定时任务扫描到已取消，例如定时任务在0分钟时执行，恰巧订单在一分钟时来了，定时任务在30分钟时扫描订单，发现订单还没过期，但是31分钟订单恰好过期，于是等到60分钟，定时任务再次扫描时，才能扫描到这个过期订单，所以订单在一分钟被创建，60分钟才被发现过期)

2)RabbitMQ延时队列

rabbitmq延时队列 (消息ttl和死信Exchange结合)

3、消息的TTL(time to live)

消息的ttl就是消息的存活时间

RabbitMQ可以对队列和消息分别设置TTL

• 对队列设置ttl就是，消息在队列的逗留时间；也可以对每一个单独的消息做单独的设置。超过了这个时间，我们就认为这个消息死了，称之为死信

• 如果队列设置了ttl，消息也设置了，会取两者之间较小的。可以通过设置消息的expiration字段或者x-message-ttl属性来设置时间，两者是一样的效果

4、Dead Letter Exchange (DLX)

5、延时队列的实现

设置队列过期时间实现延时队列 (推荐)

设置消息过期时间来实现延时队列

6、延时队列定时关闭订单模拟

交换机，队列以及路由键的相关情况如下：

p消息，经过交换机order-event-exchange路由到延时队列order.delay.queue，延时队列设置了如上三个属性，当延时队列中的消息过期后，会转到指定的Dead Letter Exchage(order-event-exchange)，Dead Letter Exchage在将消息路由到指定的队列进行处理

7、消息丢失、积压、重复的解决方案

如何保证消息的可靠性

1、消息丢失

消息发送出去，由于网络原因没有到达服务器(producer到broker)

• 做好容错方法(try catch)，发送消息可能会网络失败，失败后要有重试机制，科技路到数据库，采用定期扫描重发的方式

• 做好日志记录，每个消息是否被服务器收到，应该记录

• 做好定期重发，定期去数据库扫描未成功发送的消息进行重发

消息抵达Broker，Broker要将消息写入磁盘(持久化)才算成功。此时Broker尚 未持久化完成，宕机

• publisher也必须加入确认回调机制，确认成功的消息，修改数据库消息状态

自动ACK的状态下。消费者收到消息，但没来得及消息然后宕机

• 一定开启手动ACK，消费成功才移除，失败或者没来得及处理就noAck并重新入队

2、消息重复

消息消费成功，事务已经提交，ack时，机器宕机。导致没有ack成功，Broker的消息 重新由unack变为ready，并发送给其他消费者(当消息正在被消费者消费时，消息是unack状态，当消息被reject时，由unack变为ready；当消息被正常消费时，从队列移除)

• 消费者的业务消费接口应该设计为幂等性的。比如扣库存有 工作单的状态标志

• 使用防重表(redis/mysql)，发送消息每一个都有业务的唯 一标识，处理过就不用处理

• rabbitMQ的每一个消息都有redelivered字段，可以获取是否 是被重新投递过来的，而不是第一次投递过来的

3、消息积压

消费者宕机积压

消费者消费能力不足积压

发送者发送流量太大

• 上线更多的消费者，进行正常消费

• 上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理