订单超时怎么处理？我们用这种方案

作者：黄晓萌(学仁)

背景

在企业的商业活动中，订单是指交易双方的产品或服务交易意向。交易下单负责创建这个交易双方的产品或服务交易意向，有了这个意向后，买方可以付款，卖方可以发货。

在电商场景下，买卖双方没有面对面交易，许多情况下需要通过超时处理自动关闭订单，下面是一个订单的流程：

如上图所示，一个订单流程中有许多环节要用到超时处理，包括但不限于：

• 买家超时未付款：比如超过15分钟没有支付，订单自动取消。

• 商家超时未发货：比如商家超过1个月没发货，订单自动取消。

• 买家超时未收货：比如商家发货后，买家没有在14天内点击确认收货，则系统默认自动收货。

JDK 自带的延时队列

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

1. 把订单插入DelayQueue中，以超时时间作为排序条件，将订单按照超时时间从小到大排序。

2. 起一个线程不停轮询队列的头部，如果订单的超时时间到了，就出队进行超时处理，并更新订单状态到数据库中。

3. 为了防止机器重启导致内存中的DelayQueue数据丢失，每次机器启动的时候，需要从数据库中初始化未结束的订单，加入到DelayQueue中。

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

• 缺点：

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

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

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

RabbitMQ的延时消息

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

• RabbitMQ Delayed Message Plugin

• 消息的TTL+死信Exchange

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解决方案，先要了解两个概念：