,另外如果库存不足了,直接由下单页返回到详情页,前端置灰下单按钮阻止用户的无效请求;
风控、网络安全 有时候我们会判断出用户是有问题的,比如某个用户开开团前一个小时开始极其高频的请求数据(1S刷新10...下单异步化 or 限流,其实在我们前面讲了数据全部进缓存了,那么其实普通业务仅仅是查询,我们redis集群抗个几十万qps并发不存在任何问题了....比如做到商品层面,每个商品每秒可下单多少多少...这样,因为我们其实不太怕大量DML,而是怕同一行大量DML;
第三种方案: 据我所知目前有些公司会再mysql层面再做一层开发,他会有行锁竞争的时候在行后追加一个队列...,把行锁转换为队列,这样其实也可以很大程度上解决性能问题,排队效率必然比并发竞争阻塞要高得多得多(锁竞争情况下 InnoDB 内部的死锁检测,以及 MySQL Server 和 InnoDB 的切换会比较消耗性能...,避免长期锁住库存让其他人无法购买;
订单超时取消存在一个无法在过期的一瞬间即时处理超时订单的问题
举个例子,比如团购下单接口有个订单15分钟超时取消订单的操作,但是呢我们有时候没有办法一下子处理那么多订单