关于高并发流量的应对可以看我之前写的https://www.jianshu.com/p/f5271c825eb9
零 补充一个下单模式的选型
下单减库存,即当买家下单后,在商品的总库存中减去买家购买数量...,不要等用户点了无数次下单,一个个尝试库存是否充足,另外呢即使这样,由于秒杀的高并发高流量,依然可能用户拿到的库存大于服务端库存,因此当用户下单的时候,如果因为库存原因下单失败呢,我们就进行前端拿到的库存值的更新...,把行锁转换为队列,这样其实也可以很大程度上解决性能问题,排队效率必然比并发竞争阻塞要高得多得多(锁竞争情况下 InnoDB 内部的死锁检测,以及 MySQL Server 和 InnoDB 的切换会比较消耗性能...,避免长期锁住库存让其他人无法购买;
订单超时取消存在一个无法在过期的一瞬间即时处理超时订单的问题
举个例子,比如团购下单接口有个订单15分钟超时取消订单的操作,但是呢我们有时候没有办法一下子处理那么多订单...;
异步化,在以下情况下可以采用异步化回滚的方式
如果我们对上游的调用量没有一个很好的预估或者上游的取消订单流量极其不规律
上游业务不关心返回值或者上游业务不需要立即知晓回滚结果
那么这里我们可以采用异步