原创

分布式消息中间件(十三)——RocketMQ延时消息

在第一章概述中,我们的背景案例存在一个问题——状态补偿问题。也就是说,订单系统需要一种补偿机制去确认某些订单的最终状态。比如,因为网络等原因,订单系统没收到“成功”的支付通知,此时订单的状态就是不确定的。一种常见的思路是:订单系统后台起一个定时任务,每隔一段时间扫描下所有”中间状态“的订单,确认下是否要关闭它。但是这种方案在订单量小的情况下还好说,一旦订单量大了,就会出现性能瓶颈,而且重复扫描的效率也太低。

本章,我们就来看下如何通过RocketMQ来解决这个问题。在RocketMQ中,有两种特殊类型的消息:定时消息延时消息

一、延时消息

所谓延时消息, 就是当Producer将消息发送到MQ后,这条消息不会立马被Consumer消费到,而是延迟一定时间后后才能被消费到。

Producer在发送延时消息时,需要设定一个延时时间长度,消息将从当前发送时间点开始延迟固定时间之后,才能被消费到。

比如在订单系统中,在订单创建时会发送一条延时消息,指定延时时间长度为30分钟,那这条消息将会在 30 分钟后才能被消费者消费到,消费者收到此消息后需要判断对应的订单是否已完成支付。如支付未完成,则关闭订单,如已完成支付则忽略。

通过这种方式,我们就可以解决订单系统的状态补偿问题:



1.1 延时级别

RocketMQ默认支持一些延迟级别:1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h。比如,Producer设置消息的延迟级别为3,意思就是延迟10s,那发送出去的消息,会过10s才会被消费者获取到。对于我们的订单延时扫描场景,可以设置延迟级别为16,也就是对应上面的30分钟。

二、定时消息

RocketMQ除了支持延时消息外,还支持定时消息。 定时消息,顾名思义,就是Producer将消息发送到MQ时,需要指定这条消息能被消费的具体时间点,只要到达具体时间点后,消费者才能消费到该消息。

可以通过定时消息触发一些定时任务,比如在某一固定时间点向用户发送提醒消息。

三、总结

本章,我们介绍了RocketMQ中的延时消息,这是一个非常有用的功能。当订单系统的订单数量非常多时,我们完全可以部署几个“订单扫描服务”,然后订阅订单消息的Topic,这样就可以很高效的处理这类状态补偿问题。

正文到此结束
本文目录