[业务逻辑] 订单超时怎么处理

文章目录

- - 1.订单的过程分析
  - 2.JDK自带的延时队列 (单机)
  - 3.RabbitMQ的延时消息 (消息队列方案)
  - 4.RocketMQ的定时消息 (消息队列方案)
  - 5.Redis过期监听 (Redis方案)
  - 6.定时任务分布式批处理 (扫表轮训方案)
  - 7.总结

1.订单的过程分析

在这里插入图片描述

一个订单流程中有许多环节要用到超时处理

买家超时未付款：比如超过15分钟没有支付，订单自动取消。
商家超时未发货：比如商家超过1个月没发货，订单自动取消。
买家超时未收货：比如商家发货后，买家没有在14天内点击确认收货，则系统默认自动收货。

超时订单的结局方式:

扫表轮训
懒删除
消息队列实现
Redis实现

2.JDK自带的延时队列 (单机)

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

在这里插入图片描述

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

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

缺点：

所有超时处理订单都要加入到DelayQueue中，占用内存大。
没法做到分布式处理，只能在集群中选一台leader专门处理，效率低。
不适合订单量比较大的场景。

3.RabbitMQ的延时消息 (消息队列方案)

RabbitMQ Delayed Message Plugin
消息的TTL+死信Exchange

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

消息的TTL+死信Exchange解决方案:

在这里插入图片描述

定义一个BizQueue，用来接收死信消息，并进行业务消费。
定义一个死信交换机(DLXExchange)，绑定BizQueue，接收延时队列的消息，并转发给BizQueue。
定义一组延时队列DelayQueue_xx，分别配置不同的TTL，用来处理固定延时5s、10s、30s等延时等级，并绑定到DLXExchange。
定义DelayExchange，用来接收业务发过来的延时消息，并根据延时时间转发到不同的延时队列中。

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

不灵活，只能支持固定延时等级。
使用复杂，要配置一堆延时队列。

4.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定时消息的实现:

使用了经典的时间轮算法, 通过TimerWheel来描述时间轮不同的时刻，通过TimerLog来记录不同时刻的消息。
TimerWheel中的每一格代表着一个时刻，同时会有一个firstPos指向这个刻度下所有定时消息的首条TimerLog记录的地址，一个lastPos指向这个刻度下所有定时消息最后一条TimerLog的记录的地址。并且，对于所处于同一个刻度的的消息，其TimerLog会通过prevPos串联成一个链表。

在这里插入图片描述

当需要新增一条记录的时候，例如现在我们要新增一个 “1-4”。那么就将新记录的 prevPos 指向当前的 lastPos，即 “1-3”，然后修改 lastPos 指向 “1-4”。这样就将同一个刻度上面的 TimerLog 记录全都串起来了。

在这里插入图片描述

优点:

精度高，支持任意时刻。
使用门槛低，和使用普通消息一样。

缺点

使用限制：定时时长最大值24小时。
成本高：每个订单需要新增一个定时消息，且不会马上消费，给MQ带来很大的存储成本。
同一个时刻大量消息会导致消息延迟：定时消息的实现逻辑需要先经过定时存储等待触发，定时时间到达后才会被投递给消费者。因此，如果将大量定时消息的定时时间设置为同一时刻，则到达该时刻后会有大量消息同时需要被处理，会造成系统压力过大，导致消息分发延迟，影响定时精度。

5.Redis过期监听 (Redis方案)

删除过期的key的时候, 进行判断状态是否是超时状态, 然后进行关闭订单
在这里插入图片描述

Redis支持过期监听，也能达到和RocketMQ定时消息一样的能力

1.redis配置文件开启"notify-keyspace-events Ex"

在这里插入图片描述

2.监听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 + "已过期");
    }
}

在这里插入图片描述

在实际生产上不推荐

每当我们对一个key设置了过期时间，Redis就会把该key带上过期时间，存到过期字典中，在redisDb中通过expires字段维护：


typedef struct redisDb {
    dict *dict;    /* 维护所有key-value键值对 */
    dict *expires; /* 过期字典，维护设置失效时间的键 */
    ....
} redisDb;

过期字典本质上是一个链表

key是一个指针，指向某个键对象。
value是一个long long类型的整数，保存了key的过期时间。

在这里插入图片描述

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

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

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

如果无法删除的话会导致库存数据始终占着, 但是未支付也未取消支付。

6.定时任务分布式批处理 (扫表轮训方案)

开启一个定时任务去扫描订单表, 获取待支付状态的数据, 判断将一些超时状态的数据进行批量修改状态。

在这里插入图片描述

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

在这里插入图片描述

稳定性强：基于通知的方案（比如MQ和Redis），比较担心在各种极端情况下导致通知的事件丢了。使用定时任务跑批，只需要保证业务幂等即可，如果这个批次有些订单没有捞出来，或者处理订单的时候应用重启了，下一个批次还是可以捞出来处理，稳定性非常高。
效率高：基于MQ的方案，需要一个订单一个定时消息，consumer处理定时消息的时候也需要一个订单一个订单更新，对数据库tps很高。使用定时任务跑批方案，一次捞出一批订单，处理完了，可以批量更新订单状态，减少数据库的tps。在海量订单处理场景下，批量处理效率最高。
可运维：基于数据库存储，可以很方便的对订单进行修改、暂停、取消等操作，所见即所得。如果业务跑失败了，还可以直接通过sql修改数据库来进行批量运维。
成本低：相对于其他解决方案要借助第三方存储组件，复用数据库的成本大大降低。

缺点：没法做到精度很高。定时任务的延迟时间，由定时任务的调度周期决定。如果把频率设置很小，就会导致数据库的qps比较高，容易造成数据库压力过大，从而影响线上的正常业务。
所以一般需要抽离出超时中心和超时库来单独做订单的超时调度

在这里插入图片描述