我们先考虑一个正常的电商购物流程,一般来说我们作为用户在一个点上APP上都会选择一些商品加入购物车,然后对购物车里选择的一些商品统一下一个订单,此时后台的订单系统必然会在订单数据库中创建一个订单。
但是我们下了一个订单之后,虽然订单数据库里会有一个订单,订单的状态却是"待支付"状态,因为此时你还没有支付这个订单,我们的订单系统其实也在等待订单用户完成这个订单的支付。
这里就有两种可能了,一种是用户下单之后立马就支付掉了,那么接着订单系统可以走后续的流程,比如通过MQ发送消息通知优惠券系统给用户发放优惠券等等。
另外一种可能是用户下单后,一直在犹豫,迟迟没有下订单。
因此在实际情况中吗,其实APP的大量用户每天会下很多订单,但是不少订单可能是一直没有进行支付的,可能他下了单之后犹豫了,可能是他忘了支付了。
所以一般订单系统都必须设置一个规则, 当一个订单下单之后,比如超过30分钟没有支付,那么就必须自动关闭这个订单,后续你如果要购买这个订单里的商品,就要重新下订单了。
可能你的订单系统就需要有一个后台线程,不停的扫描订单数据库里所有的未支付状态的订单,看他如果超过30分钟还没支付,就自动把订单状态改成“已关闭”。
但是这里就引入一个问题,就是订单系统的后台线程必须要不停的扫描各种未支付的订单,这种实现方式实际上并不是很好。
一个原因是未支付状态的订单可能是比较多,然后你需要不停的扫描他们, 可能每个未支付状态的订单要被扫描N多遍,才会发现他已经超过30分钟未支付了。
另外一个是很难去分布式并行扫描你的订单,因为假设你的订单数量特别多,然后你要是打算用多台机器部署订单扫描服务&#x