今天，L同学微信给我发消息说：“学长，大事不好了，面试官问我电商场景的日均百万订单的高并发如何处理，这应该如何回答才好呢？”
还没等我回复消息，L同学的第二条消息接踵而至了：“就是那些库存高并发扣减、防止库存超卖这些问题。”
我问L同学：“那你是如何回答的呢？”
L同学同学发了一个小脸儿涨得通红的表情，说：“我就说了个MySQL肯定扛不住，需要通过Redis进行库存扣减，然后面试官听了摇了摇头，嘴角露出了一抹讥讽的笑意。”
我突发感慨道：“MySQL君啊，这么多年委屈你了，你到底蒙受了多少不白之冤啊。”
L同学问：“啊？这是什么意思？”
我说：“其实这不是一个技术问题，而是一个智商题，只要掌握最简单的数学计算，就可以回答上来。”
其实真的是这样，并没有一点儿语不惊人死不休的意思。
我们计算一下，日均百万订单，只要不是存在非常明显的业务波峰波谷的情况，那每个小时十万订单也就顶天儿了，然后我们再除以3600秒，得出来的结果是，下单接口的TPS连30都不到。
你管这玩意儿叫高并发？还说什么高并发库存扣减？
然后再说说所谓的库存超卖问题，这个更是无稽之谈，我来解释一下。
正常情况下，一个日均百万订单的电商平台，商品数量至少得一万以上吧，下单接口30的TPS，别说库存超卖了，每秒钟同一个商品的库存被扣减两次的概率都非常低。
当然，如果想彻底规避超卖问题，那其实更简单，一条SQL语句就搞定了。
update 商品表 set 库存数量 = 库存数量 - 1 where 库存数量 > 0
这条SQL语句具备了库存扣减和库存校验的双重职责，同时也具备原子性和隔离性的特点，所以永远都不会产生并发场景下的库存超卖问题。
有人会问，为什么不用分布式锁解决库存扣减问题啊？
我只能说，你快拉倒吧，别认为制造系统复杂度了。
世界上解决一个计算机问题最简单的方法是 —— “恰好” 不需要解决它。
很多所谓的“架构师”，一旦他们手里有了锤子，那真的是看什么都觉得像钉子。
嗯，所以来说，定点准时的单品秒杀场景是高并发技术问题，而日均百万单的高并发场景，这只是个智商题而已。
