RabbitMQ 之延时任务

场景：

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

常用解决方案：

Spring的schedule定时任务轮询数据库

缺点：

• 消耗系统内存
• 增加了数据库的压力
• 存在较大的时间误差

MQ解决方案:

rabbitmq的消息TTL和死信Exchange结合

消息的TTL

1. 消息的TTL就是消息的存活时间
2. RabbitMQ可以对队列和消息分别设置TTL

•  对队列设置就是队列没有消费者连接的保留时间，也可以对每一个单独的消息做单独的设置。超过了这个时间，我们就认为这个消息死了，称之为死信。
• 如果队列设置了，消息也设置了，那么就会去最小的，所以一个消息如果被路由到不同的队列中，那么这个消息的死亡时间有可能不一样（不同的队列设置过期不同导致）。这里讲的单个消息的TTL，因为消息才是实现延时任务的关键。可以通过设置消息的expiration字段或者x-message-ttl属性设置时间，两者是一样的效果。

设置队列消息过期时间延时队列

给队列设置过期时间

 

给消息设置过期时间

建议使用给{队列}设置过期时间，如果是给消息进行设置过期时间，MQ是惰性检查，如果第一个是5min,第二个是1min,第三个是1s,如果过来检查发现是5分钟，那么将会在5分钟后进行检查，这样后面的消息就会延时了5分钟

 

 

订单创建消费及其延时队列

 

如何保证消息可靠性：

1. 消息丢失

• 消息发出去，由于网络问题没有抵达服务器

1. 做好容错方法，发送消息可能会网络失败，失败后要有重试机制，可以记录到数据库中，采用定期扫描重发。
2. 做好日志记录，每个消息是否被服务器收到都应该记录
3. 做好定期重发，如果消息没有成功发送，定期去数据库扫描未发送成功的消息进行重发

• 消息抵达Broker,Broker要将消息写入磁盘（持久化）才算成功.

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

• 自动Ack状态下，消费者刚收到消息，没来得及消费宕机了

1. 一定要开启手动ack,消费成功才能移除，失败或者没来得及处理就noAck并重新入队  

2. 消息重复

1. 消息消费成功，事务已经提交，ack时，机器宕机，导致ack没有成功，Broker的消息重新有unack变为ready,并发送给其他消费者
2. 消息消费失败，由于重试机制，自动有将消息进行发送
3. 消费者的业消费接口应该设计为幂等性的,比如扣库存有工作单的状态标志
4. 使用防重表，发送消息每一个都有业余唯一标识，处理过就不用了处理
5. rabbitMq的每一个消息都有redelivered字段，可以获取是否是被重新投递过来的，而不是第一次投递过来

3. 消息积压

1. 消费者宕机积压
2. 消费者消费能力不足积压
3. 发送者流量太大
   1. 上线更多消费者，进行正常消费
   2. 上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理