订单超时自动取消订单实现策略

订单超时，自动取消，在生活中很常见。比如整点秒杀时，下单后，三十分钟没有付款。这个订单就会被自动取消。这个操作的实现策略有下面这几个：

方案一：使用JDK自带的延迟队列

JDK中提供了一种延迟队列数据结构DelayQueue，其本质是封装了PriorityQueue，可以把元素进行排序。

把订单插入DelayQueue中，以超时时间作为排序条件，将订单按照超时时间从小到大排序。起一个线程不停轮询队列的头部，如果订单的超时时间到了，就出队进行超时处理，并更新订单状态到数据库中。为了防止机器重启导致内存中的DelayQueue数据丢失，每次机器启动的时候，需要从数据库中初始化未结束的订单，加入到DelayQueue中。

• 优点：简单，不需要借助其他第三方组件，成本低。

• 缺点：

• • 所有超时处理订单都要加入到DelayQueue中，占用内存大。

  • 没法做到分布式处理，只能在集群中选一台leader专门处理，效率低。

  • 不适合订单量比较大的场景。

  • 因为内存条件限制的原因，比如下单未付款的订单数太多，那么很容易就出现 OOM 异常

方案二：RocketMQ的定时消息

RocketMQ支持任意秒级的定时消息，如下图所示；

代码示例如下：

MessageBuilder messageBuilder = null;
Long deliverTimeStamp = System.currentTimeMillis() + 10L * 60 * 1000; //延迟10分钟
Message message = messageBuilder.setTopic("topic")
//设置消息索引键，可根据关键字精确查找某条消息。
 .setKeys("messageKey")        
//设置消息Tag，用于消费端根据指定Tag过滤消息。 
 .setTag("messageTag")        
//设置延时时间  
.setDeliveryTimestamp(deliverTimeStamp)         
//消息体 
 .setBody("messageBody".getBytes()).build();
SendReceipt sendReceipt = producer.send(message);
System.out.println(sendReceipt.getMessageId());

RocketMQ的定时消息是如何实现的呢？

在RocketMQ中，使用了经典的时间轮算法[1]。通过TimerWheel来描述时间轮不同的时刻，通过TimerLog来记录不同时刻的消息。

• 优点

• • 精度高，支持任意时刻。

  • 使用门槛低，和使用普通消息一样。

• 缺点

• • 使用限制：定时时长最大值24小时。

  • 成本高：每个订单需要新增一个定时消息，且不会马上消费，给MQ带来很大的存储成本。

  • 同一个时刻大量消息会导致消息延迟：定时消息的实现逻辑需要先经过定时存储等待触发，定时时间到达后才会被投递给消费者。因此，如果将大量定时消息的定时时间设置为同一时刻，则到达该时刻后会有大量消息同时需要被处理，会造成系统压力过大，导致消息分发延迟，影响定时精度。

方案三：Redis的过期监听

该方案使用 redis 的 Keyspace Notifications，中文翻译就是键空间机制，就是利用该机制可以在 key 失效之后，提供一个回调，实际上是 redis 会给客户端发送一个消息。是需要 redis 版本 2.8 以上。

Redis支持过期监听，也能达到和RocketMQ定时消息一样的能力，具体步骤如下：

redis配置文件开启"notify-keyspace-events Ex" （开启过期监听的配置）

示例代码如下，监听key的过期回调

@Configuration
public class RedisListenerConfig { 
 @Bean   
RedisMessageListenerContainer container(RedisConnectionFactory factory)
    {        
        RedisMessageListenerContainer container=new RedisMessageListenerContainer();  
        container.setConnectionFactory(factory); 
        return container;    
     }
}

@Component
public class RedisKeyExpirationListerner extends KeyExpirationEventMessageListener { 
    public RedisKeyExpirationListerner(RedisMessageListenerContainer listenerContainer) {
                super(listenerContainer);   
     }

    @Override 
    public void onMessage(Message message, byte[] pattern) { 
            String keyExpira = message.toString();
            System.out.println("监听到key：" + expiredKey + "已过期");
     }
}

示例流程图如下：

Redis主要使用了定期删除和惰性删除策略来进行过期key的删除

• 定期删除：每隔一段时间（默认100ms）就随机抽取一些设置了过期时间的key，检查其是否过期，如果有过期就删除。之所以这么做，是为了通过限制删除操作的执行时长和频率来减少对cpu的影响。不然每隔100ms就要遍历所有设置过期时间的key，会导致cpu负载太大。

• 惰性删除：不主动删除过期的key，每次从数据库访问key时，都检测key是否过期，如果过期则删除该key。惰性删除有一个问题，如果这个key已经过期了，但是一直没有被访问，就会一直保存在数据库中。

从以上的原理可以得知[2]，Redis过期删除是不精准的，在订单超时处理的场景下，惰性删除基本上也用不到，无法保证key在过期的时候可以立即删除，更不能保证能立即通知。如果订单量比较大，那么延迟几分钟也是有可能的。

Redis过期通知也是不可靠的，Redis在过期通知的时候，如果应用正好重启了，那么就有可能通知事件就丢了，会导致订单一直无法关闭，有稳定性问题。如果一定要使用Redis过期监听方案，建议再通过定时任务做补偿机制。

方案四：RabbitMQ的延时消息

RabbitMQ的延时消息主要有两个解决方案；

• 消息的TTL+死信Exchange

• RabbitMQ Delayed Message Plugin

RabbitMQ Delayed Message Plugin是官方提供的延时消息插件，虽然使用起来比较方便，但是不是高可用的，如果节点挂了会导致消息丢失。引用官网原文：

Delayed messages are stored in a Mnesia table (also see Limitations below) with a single disk replica on the current node. They will survive a node restart. While timer(s) that triggered scheduled delivery are not persisted, it will be re-initialised during plugin activation on node start. Obviously, only having one copy of a scheduled message in a cluster means that losing that node or disabling the plugin on it will lose the messages residing on that node.

消息的TTL+死信Exchange解决方案，先要了解两个概念：

• TTL：即消息的存活时间。RabbitMQ可以对队列和消息分别设置TTL，如果对队列设置，则队列中所有的消息都具有相同的过期时间。超过了这个时间，我们认为这个消息就死了，称之为死信。

• 死信Exchange（DLX）：一个消息在满足以下条件会进入死信交换机

• • 一个消息被Consumer拒收了，并且reject方法的参数里requeue是false。也就是说不会被再次放在队列里，被其他消费者使用。

  • TTL到期的消息。

  • 队列满了被丢弃的消息。

一个延时消息的流程如下图：

1. 定义一个BizQueue，用来接收死信消息，并进行业务消费。

2. 定义一个死信交换机(DLXExchange)，绑定BizQueue，接收延时队列的消息，并转发给BizQueue。

3. 定义一组延时队列DelayQueue_xx，分别配置不同的TTL，用来处理固定延时5s、10s、30s等延时等级，并绑定到DLXExchange。

4. 定义DelayExchange，用来接收业务发过来的延时消息，并根据延时时间转发到不同的延时队列中。

• 优点：可以支持海量延时消息，支持分布式处理。

• 缺点：

• • 不灵活，只能支持固定延时等级。

  • 使用复杂，要配置一堆延时队列。

方案五:定时任务分布式批处理

定时任务分布式批处理解决方案，即通过定时任务不停轮询数据库的订单，将已经超时的订单捞出来，分发给不同的机器分布式处理：

使用定时任务分布式批处理的方案具有如下优势：

• **稳定性强：**基于通知的方案（比如MQ和Redis），比较担心在各种极端情况下导致通知的事件丢了。使用定时任务跑批，只需要保证业务幂等即可，如果这个批次有些订单没有捞出来，或者处理订单的时候应用重启了，下一个批次还是可以捞出来处理，稳定性非常高。

• **效率高：**基于MQ的方案，需要一个订单一个定时消息，consumer处理定时消息的时候也需要一个订单一个订单更新，对数据库tps很高。使用定时任务跑批方案，一次捞出一批订单，处理完了，可以批量更新订单状态，减少数据库的tps。在海量订单处理场景下，批量处理效率最高。

• **可运维：**基于数据库存储，可以很方便的对订单进行修改、暂停、取消等操作，所见即所得。如果业务跑失败了，还可以直接通过sql修改数据库来进行批量运维。

• **成本低：**相对于其他解决方案要借助第三方存储组件，复用数据库的成本大大降低。

但是使用定时任务有个天然的缺点：没法做到精度很高。定时任务的延迟时间，由定时任务的调度周期决定。如果把频率设置很小，就会导致数据库的qps比较高，容易造成数据库压力过大，从而影响线上的正常业务。

所以一般需要抽离出超时中心和超时库来单独做订单的超时调度，在阿里内部，几乎所有的业务都使用基于定时任务分布式批处理的超时中心来做订单超时处理，SLA可以做到30秒以内.

方案六：Redis的zset实现

我们可以借助Redis中的有序集合------zset来实现这个功能。

zset是一个有序集合，每一个元素(member)都关联了一个 score，可以通过 score 排序来取集合中的值。

我们将订单超时时间的时间戳（下单时间+超时时长）与订单号分别设置为 score 和 member。这样redis会对zset按照score延时时间进行排序。然后我们再开启redis扫描任务，获取"当前时间 > score"的延时任务，扫描到之后取出订单号，然后查询到订单进行关单操作即可。

使用redis zset来实现订单关闭的功能的优点是可以借助redis的持久化、高可用机制。避免数据丢失。但是这个方案也有缺点，那就是在高并发场景中，有可能有多个消费者同时获取到同一个订单号，一般采用加分布式锁解决，但是这样做也会降低吞吐型。

但是，在大多数业务场景下，如果幂等性做得好的，多个消费者取到同一个订单号也无妨。

方案七：被动关闭方式

这种方式，就是当用户再次查询或者用户点击支付时，后台对订单是否超时，进行判断。如果超时，将订单进行关闭。然后在提醒用户，订单已超时，被取消了。

这种做法是最简单的，基本不需要开发定时关闭的功能，但是他的缺点也很明显，那就是如果用户一直不来查看这个订单，那么就会有很多脏数据冗余在数据库中一直无法被关单。

还有一个缺点，那就是需要在用户的查询过程中进行写的操作，一般写操作都会比读操作耗时更长，而且有失败的可能，一旦关单失败了，就会导致系统处理起来比较复杂。

所以，这种方案只适合于自己学习的时候用，任何商业网站中都不建议使用这种方案来实现订单关闭的功能。

总结：

如果对于超时精度比较高，超时时间在24小时内，且不会有峰值压力的场景，推荐使用RocketMQ的定时消息解决方案。

在电商业务下，许多订单超时场景都在24小时以上，对于超时精度没有那么敏感，并且有海量订单需要批处理，推荐使用基于定时任务的跑批解决方案。

点点关注呀，持续更新有用的知识............