通过 **RocketMQ 延时消息特性**，完成用户购票 10 分钟后未支付情况下取消订单功能；

描述一下技术选型的问题：

​ 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 的消息传递机制保证了消息的可靠性传递，因此消息可能会进行多次重试。为了确保订单关闭操作的幂等性，即多次执行不会产生副作用，我们需要在订单关闭逻辑中进行幂等性的处理。