【个人笔记】mq超时取消订单

对下单场景可能遇到的一些问题的思考
下单过程：请求-> 下单 + 锁库存->支付

1. 场景一：下单 + 锁库存（如何提高响应速度）

不要求响应速度：先加锁（保证线程安全），判断库存是否足够，足够的话库存-1，再创建订单，订单初始化为待支付状态，然后返回处理结果。
优化思路：只要创建订单，就要频繁操作数据库 IO。可以通过预扣库存来避免直接操作数据库 IO，即用redis统一存库存（redis号称单机 QPS 能抗 10W 的并发），下单过程变为：请求----redis减库存----在mysql减库存+创建订单----支付
具体优化方案：预扣库存（用mq+redis进行优化），目的是提高响应速度。redis存放库存数量，先在redis判断库存是否足够，足够的话库存-1并返回处理结果，并发送消息到MQ的消息队列中，通过消费者异步在数据库减库存并创建订单，这样响应给用户的速度就会快很多（预扣完库存就能返回响应）。生成订单时，订单状态初始化为待支付。

图

2. 场景二：支付（如何保证不少卖和强一致性）

注意：调用第三方支付的话，第三方会提供回调通知，服务端通过第三方的回调通知，可以知道第三方订单的状态，从而决定是否订单过期。
（1）用户下单后，一直不支付怎么办？（怎么保证不少卖）
为了防止用户下单后既不取消也不付款，导致库存一直被锁定，卖不出去，设置五分钟的过期时间，用户五分钟内不支付，就设置订单为取消状态，并释放库存（加锁使库存+1）。
如果订单量不大，用定时任务比如spring task或者分布式定时任务xxl-job去定时扫表就行了，但有个问题就是，每个订单的下单时间不一样，而定时任务是一次性扫描整表，如果定时时间设置短一点，30s查一次，太频繁了，表里数据量大的话，更耗性能。如果设置长一点5分钟查一次，那又会处理不及时。
所以需要考虑用mq延时队列，每创建一个支付订单都要放到延时队列，超时就去数据库查询有没有支付成功，没有就取消订单（设置状态为已取消），性能问题好说，比如增加消费者数量以加快处理速度，再比如增加数据库集群数量，来解决数据库性能不足的问题。
（2）用户下单后，支付了已取消的订单怎么办？（怎么保证强一致性）
为了防止用户卡在取消订单前跳转到支付页面进行支付导致的订单被取消而用户支付成功的问题，可以在取消订单的同时也取消支付接口（第三方支付的接口也是可以取消的！），取消之后用户就会付款失败，万一用户真的支付成功了，就等第三方支付成功的回调，返回回调的话就对已经取消的订单走退款，从而保证资金的幂等。
这里还可以有一种设置，就是设置5分钟超时后，mq只是去检验哪些订单超时了，设置订单为取消状态并且取消支付接口，再等1分钟之后（而不是马上）才会去释放库存（库存+1），如果这一分钟里面如果能接到支付成功的回调，就重新设置订单为支付成功。当然如果回调也超时那就得退款了（最后订单还是取消了）。

其他：像商品那种库存比较多的，可以设置只有库存低了才去预防超卖，或者只放出70%的库存，留一定的余量防止超卖，或者超卖后店家直接补一批货发出去得了，但像预约数量那种场景就没必要设置只有库存低了才去预防超卖，因为预约数本来就不多