rabbitmq延时队列应用

rabbitmq延时队列（实现定时任务）

场景

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

常用解决方案

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

缺点

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

解决

rabbitmq的消息TTL和死信Exchange结合

消息的TTL(Time To Live)

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

延时队列实现的二种方式

消息队列流程（示例）

柔性事物--可靠消息+最终一致性方案（异步确保型）

实现：业务处理服务在业务事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不是真正的发送。业务处理服务在业务事务提交之后，向实时消息服务确认发送。只有在得到发送指令后，实时消息服务才会真正发送。

如何保证消息的可靠性

消息丢失

• 消息发送出去，由于网络问题没有抵达服务器
  • 做好容错方法（try-catch），发送消息可能会网络失败，失败后要有重试机制，可记录到数据库，采用定期扫描重发的方式
  • 做好日志记录，每个消息状态是否都被服务器收到都应该记录
  • 做好定期重发，如果消息没有发送成功，定期去数据库扫描未成功的消息进行重发
• 消息抵达Broker，Broker要将消息写入磁盘（持久化）才算成功。此时Broker尚未持久化完成，宕机。
  • publish也必须加入确认回调机制，确认成功的消息，修改数据库消息状态。
• 自动ACK的状态下。消费者收到消息，但没有来得及消费然后宕机。
  • 一定开启手动ACK，消费成功才移除，失败或者没有来得及处理就noACK并重新入队

Rabbit消息ACK配置

待完善

消息重复

• 消息消费成功，事务已经提交，ACK时，机器宕机。导致没有ACK成功，Broker的消息重新由unack变为ready，并发送给其他消费者
• 消息消费失败，由于重试机制，自动又将消息发送出去
• 成功消费，ACK时宕机，消息由uncheck变为ready，Broker又重新发送
  • 消费者的业务消费接口应该设计为幂等性的。比如扣库存有工作单的状态标志
  • 使用防重表（redis/mysql)，发送消息每一个都有业务的唯一标识，处理过就不用处理
  • rabbitMQ的每一个消息都有redelivered字段，可以获取是否是被重新投递过来的，而不是第一次投递过来的

消息积压

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