西西河

主题:【原创】无责任推测12306网站遇到的麻烦 -- 代码ABC

共:💬135 🌺246
全看树展主题 · 分页首页 上页
/ 9
下页 末页
家园 12306每天只卖100万张票

只是比电话售票多一点而已。所以这个系统并不怎么样。

家园 看见黑影就开枪

不过说一个我看到的案例而已,你从哪里看出来我觉得印度人开发大规模系统很成功,又从哪里看出来我把他们当偶像了?

欢迎你多写几个字,拿些和主题有关的数据和实例出来让大家学习、长见识,这样河里的气氛会好很多。

家园 据说这个网站在春运期间是日均10亿次的访问量。
家园 网上、电话、窗口都是分配的不同票额,互不相干。

  网上不会把窗口的票也卖掉的。

  但反过来,网上的票额到最后几天卖不掉会转到窗口去。

家园 不知道我的理解对不对

就是说12306也就是一个全国性普通的大型购物网站的级别。

如果这样的话,做成这样子实在是不应该了,因为已经有不少国内成功先例了。

家园 这还真是个符合特殊国情的好的系统设计思路

中国人口多,不能照搬西方那一套所谓人人都平等的坏毛病。

以后新浪围脖等都需要改成单双日,上网排队,连造谣辟谣的工作量都可以减少,这些无意义的GDP应该砍掉,水军干部队伍的建设也要兼顾维持排队秩序等方面,不要把工作重心只放在与美国比烂上。

家园 今天遇到了相关的技术人员,搞明白了,网上99%的说法

都没说到点子上。有些细节恕不能详说。基本上是这样的。

网上订票系统只是一个壳子,跑在jboss上面。后面有一个legacy system,这个已经运行了近20年的老古董了,也就是在窗口售票中使用的系统。但致命的是,这个legacy system完全无法scale out,这里涉及一些细节,但每一个初级的架构师听到这个细节都会明白,确实这样是无法scale out的。

网上订票系统,原在刘志军时代是设计用来卖高铁票的,那么原设计倒是无问题的。但新部长非要卖普票,各供应商包括铁科院自己都觉得很崩溃。因为接到要卖普票的要求时,已经不到4个月的时间了,这个时候再改技术架构已经没可能了。

总之网上说的一切scale out的方案都完全无可能,原因在于其真正的transaction部分都在那个legacy system中,完全无法剥离。(理论上剥离当然可以,但时间不够,且如果春运时做这个工作,相当于连窗口售票都要崩溃,那就成了政治事件了)。

这个系统运行起来后,如果假设总体连接能力为N的话,大体只给互联网售票留了很小一部分连接能力。这样至少保证了窗口售票还能正常进行。

春运期间这事最终还是靠scale up的方式解决了,HP卖给铁道部一台128个CPU的服务器,算是这次最大的赢家了。

这个事件里还有个有意思的地方,看这贴的人应该都知道有一篇称赞淘宝架构如何NB的文章。事实是,淘宝团队1月4日就到铁科院去帮助调优了,但最终也只有选择了scale up的方案。为何后来淘宝不再唧唧歪歪了原因也在这里,从上海杭州抽调了20多个骨干精英去干这事,也没有找到更好的方法。当然了,对马云来说也是重大收获,马总对团队的指示是不计成本要帮铁道部解决这事儿,换来的就是要求铁道部支持支付宝独揽支付业务。TB算是仅次于HP的大赢家吧。

家园 技术细节不说,高阻铁定又是问题的根源
家园 如果仅仅是scale up能解决问题也好 但是搞过sys

的筒子都应该知道,系统都到那份上了。单纯的HPC式的多C小机你来一群都不够用哇。最后也只有负载均衡、主控分区、分布式站点解算等等架构性能调优才有点前途嘛。

另外貌似这样的架构还是上IBM的P系比HP\SUN更稳一点。

家园 这都是要求将业务逻辑移出Legacy System。

由于那个Legacy System的局限,目前你说的几种方案都是无法实施的,除非将业务逻辑移出该Legacy System,比如直接跑在JBoss上,那样做HA+LB毫无压力。但这个选择的主要问题在于:

1.工作量太大,这个工作量就是重新做一个购票系统,时间不够用了。你要注意的是,目前这个互联网购票系统其实只是一个壳子,真正的业务部分实际上是在那个Legacy System的,也就是大头的工作是在后端的,并不是前端互联网这块儿。实际上根据该大拿的说法,在1月份时,系统负载最高点跑JBoss/Web那端服务器的CPU负载不过10%。而后面LegacySystem早就完蛋了。

那么把这个业务逻辑重新实现一遍?那就不是几个月能够搞定的事儿了。

2.相比互联网售票,窗口售票系统的稳定性更是大局,如果窗口售票系统崩溃了,那就成了政治事件了。这也是为什么无法冒险在短时间内升级的另一个主要原因了。

我说铁科院这帮哥们儿倒霉就倒霉在团队成立初期按上任部长的思路,只卖高铁票,所以设计了这么个jboss前端+TRS的悲催方案;结果部长一换人,变成了全部票都卖的需求,时间还不够用了(只有三个月)。

当然,换句话说,如果一开始就规划成把TRS整体重写一遍,那样项目的投资恐怕翻10倍都不止。

按现在的情况,如果马云在上面的关系更NB一点的话,有可能这个系统后面的大改造就给TB做了,只是一种可能哈。

家园 另,据我了解到的,Sharding最后

他们还是做了,到一月上旬的时候,系统改成了将热门票和冷门票分开的策略,是从存储端分开的。这样热门票本来也难买,慢点也就慢点了,冷门票就没有这个问题了。

家园 首先从数据库着手更有意义吧

把热点数据与冰点数据从存储物理分离不是很那个啥

即使是这样剥离也应该是热点数据占据最好的资源比如固态硬盘和FC 冰点数据上TB的sata就是了 系统看上去才和谐嘛 符合现正流行的优化

不知道他们用的啥存储?EMC?HDS(HP/SUN)?IBM?也应该就这仨大吧。。。

家园 EMC

数据库是..... Sybase的,搞系统的人都知道这意味着什么,你懂得~~~。

家园 看来我最初的推测是靠谱的

代码ABC:蒋涛那个分析不靠谱

估计这个和铁路内部票务系统的接口有很大关系,网上售票系统其实就是等于将原有的窗口售票终端扩充了成千上万倍,而原本的售票系统查询量远远小于现在的网上售票系统。整个数据库的调优指标发生了重大变化,我估计这个系统和网站还有一定的隔离(安全考虑)所以查询效率比较低,且不容易做到交易事务的完整性。所以高峰期一到就很容易出现各种毛病,包括支付问题。

家园 我在河里写过一篇,和估计的差不多 。

链接出处

其实就是老的交易系统如果上了一个前端系统来提供互联网服务所遇到的问题。

全看树展主题 · 分页首页 上页
/ 9
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河