家说了，90%左右。在交易相关的过程中，都会多次提交查询请求，更不要说现在有大量刷票软件的出现所带来的额外增加的工作负载了，这一切都让余票查询系统成为整个系统的压力集中地。”
“我的解决方案是，星云介入后，把余票查询模块和12306现有系统做分离，具备独立部署的能力；在云端上独立部署一套余票查询系统，这样12306和云上都有了一套余票查询系统，调度会更为灵活，目前星云集群服务器规模已经达到了50000台以上。”
在场的几位铁路集团的技术专家一听也是暗暗咂嘴，难怪阿里的“飞天”系统这么不禁打，前者勉勉强强破千，而后者已经达到了5万规模之巨，难怪罗晟会这么有信心。
接下来，罗晟主要与铁路集团的几名技术专家讨论。
“今天上午我在得知消息顺带简单研究了一下‘12306’的服务端架构。”罗晟面向众人有条不紊的说道：“广大访问者都在喷，但是我知道12306服务一上线试运行，就承受着这个世界上任何秒杀系统都无法超越的QPS，上百万的并发再正常不过了。”
在场的几名铁路集团的技术骨干人员内心稀里哗啦的感动，理解万岁啊。
不懂技术的领导最难沟通，觉得没有尽力。
罗晟的话还是很有分量的。
过了片刻，罗晟补充道：“高并发的系统架构要采用分布式集群部署，服务上层有着层层负载均衡，并提供各种容灾手段，所谓的容灾手段就是双火机房、节点容错、服务器灾备等。保证系统的高可用，流量也会根据不同的负载能力和配置策略均衡到不同的服务器上。”
“即便如此，集群中的单机所能承受的QPS也是非常高的，那么如何将单机性能优化到极致呢？要解决这个问题要先弄明白一件事：通常订票系统要处理生成订单、减扣库存、用户支付这三个基本的阶段，系统要做的事情就是保证火车票订到不超卖、不少卖、每张售卖的车票都必须支付才有效，还要保证系统承受极高的并发。”
几名铁路集团的技术专家连连点头表示认同，技术痛点就在这里。
罗晟继续说道：“下单减库存。当用户并发请求到达服务端时，首先创建订单，然后扣除库存，等待用户支付。这种顺序是我们一般人首先会想到的解决方案，这种情况下也能保证订单不会超卖，但也会产生一些问题，第一就是在极限并发的情况下，任何一个内存操作的细节都至关影响性能，尤其是像创建订单这种逻辑，基本都需要存储到磁盘数据库的，对数据库的压力是可想而知的，12306应该是用的甲骨文数据库，别花这个冤枉钱了，放到我的星云上。”
“第二是
请收藏：https://m.touna.cc
（温馨提示：请关闭畅读或阅读模式，否则内容无法正常显示）