过了片刻，罗晟补充道“高并发的系统架构要采用分布式集群部署，服务上层有着层层负载均衡，并提供各种容灾手段，所谓的容灾手段就是双火机房、节点容错、服务器灾备等。保证系统的高可用，流量也会根据不同的负载能力和配置策略均衡到不同的服务器上。”
“即便如此，集群中的单机所能承受的qps也是非常高的，那么如何将单机性能优化到极致呢？要解决这个问题要先弄明白一件事通常订票系统要处理生成订单、减扣库存、用户支付这三个基本的阶段，系统要做的事情就是保证火车票订到不超卖、不少卖、每张售卖的车票都必须支付才有效，还要保证系统承受极高的并发。”
几名铁路集团的技术专家连连点头表示认同，技术痛点就在这里。
罗晟继续说道“下单减库存。当用户并发请求到达服务端时，首先创建订单，然后扣除库存，等待用户支付。这种顺序是我们一般人首先会想到的解决方案，这种情况下也能保证订单不会超卖，但也会产生一些问题，第一就是在极限并发的情况下，任何一个内存操作的细节都至关影响性能，尤其是像创建订单这种逻辑，基本都需要存储到磁盘数据库的，对数据库的压力是可想而知的，12306应该是用的甲骨文数据库，别花这个冤枉钱了，放到我的星云上。”
“第二是如果用户存在恶意下单的情况，只下单不支付这样库存就会变少，会少卖很多订单，虽然服务端可以限制ip和用户的购买订单数量，但这也真心不算是一个好办法。”
“然后就是支付减库存了。如果等待用户支付了订单再减库存，第一感觉就是不会少卖。但这是并发架构的大忌，因为在极限并发的情况下，用户可能会创建很多订单，当库存减为零的时候很多用户会发现抢到的订单支付不了，这也就是所谓的‘超卖’，也不能避免并发操作数据库磁盘io。”
“最后是预扣库存。从上面两种方案的考虑，可以得出结论只要创建订单，就要频繁操作数据库io。那么有没有一种不需要直接操作数据库io的解决方案
本章未完，请点击"下一页"继续阅读！ 第3页 / 共5页