描述一下技术选型的问题:
1.定时任务:优点在于简单易实现(例如:xxl-job)
1.延迟时间不精确:使用定时任务执行订单关闭逻辑,无法保证订单在十分钟后准确地关闭。如果任务执行器在关闭订单的具体时间点出现问题,可能导致订单关闭的时间延后。
2.不适合高并发场景:定时任务执行的频率通常是固定的,无法根据实际订单的情况来灵活调整。在高并发场景下,可能导致大量的定时任务同时执行,造成系统负载过大。
3.分库分表问题:拿 12306 来说,订单表按照用户标识和订单号进行了分库分表,那这样的话,和上面说的根据订单创建时间去扫描一批订单进行关闭,自然就行不通。因为根据创建时间查询没有携带分片键,存在读扩散问题。
2.RabbitMQ
RabbitMQ 的延时消息特性,我们可以轻松实现订单十分钟延时关闭功能,比较难搞定的是可用性问题,RabbitMQ 在可用性方面较弱,部分场景下会存在单点故障问题。
3.Redis 过期监听和Redisson也可以实现
但是存在几个问题:1.不够精确,过期时间通过定时器实现的,可能存在误差,对于某些时间要求较高的场景不合适。2.redis宕机;3.可靠性。依赖Redis的过期时间来实现,需要保证redis的高可用性和稳定性。4.版本问题,5.0之前不保证延迟消息持久化;
在订单生成时,我们将订单关闭消息发送到 RocketMQ,并设置消息的延迟时间为十分钟。RocketMQ 支持设置消息的延迟时间,可以通过设置消息的 delayLevel 来指定延迟级别,每个级别对应一种延迟时间。这样,订单关闭消息将在十分钟后自动被消费者接收到。
需要注意,RocketMQ 5.0 之后已经支持了自定义时间的延迟,而不仅是延迟级别范围内的时间。
为了处理订单关闭消息,我们需要在消费者端创建一个消息监听器。当消息监听器接收到订单关闭消息时,触发订单关闭操作,将订单状态设置为关闭状态。
需要注意的是,RocketMQ 的消息传递机制保证了消息的可靠性传递,因此消息可能会进行多次重试。为了确保订单关闭操作的幂等性,即多次执行不会产生副作用,我们需要在订单关闭逻辑中进行幂等性的处理。