讨论下12306的计算量

显示全部楼层 · 2011-12-22 10:19:42

转自网络：9日，这个网站点击量超过14亿次，相当于所有中国人当天都点击了一次。由于访问量太大，网站无法顺畅登录。
相比银行，特别是银联ATM取款的计算量。
诸位有啥高见，技术难点在哪？抛砖引玉，不知可否。

千问 · 2011-12-22 10:19:42

操作渠道不同，用户量也不同，铁道部购票网站并发数字估计能大的吓死人我完全理解，关键是阶段性并发量大，估计春节后就是小几个数量级的，这个巨大的波动是银行没有的
而ATM又的插卡，又的键盘操作，还同时分布在多家商业银行上，并发压力小多了，交易相对比较平稳和顺滑

千问 · 2011-12-22 10:19:42

本帖最后由 CountOnMyself 于 2012-1-11 20:35 编辑
网站操作大部分是属于页面的操作，我觉得压力应该是在WEB服务器上。
网站无法登录，说明了还没进入交易阶段系统已经支持不住了，应该是WEB服务器集群处理能力不足的问题吧。假设一次购票点平均点均10次，则每天处理的购票业务笔数约1.2亿次，按中国人的疯狂程度，估计是一天有20小时是忙时，则每小时至少应处理600万笔，估算下来，并发用户数应该是几十万的级别吧。
如果有几十台WEB服务器，则每台服务器只需要应付1万个并发用户左右，应该是可以实现的。
但从新闻看到，这个系统既不使用大机模式，也不使用分布式计算模式，所以支持不了这个并发量，这也是可以理解的了。

千问 · 2011-12-22 10:19:42

从我8号买票的经历来说静态页面的显示还算正常涉及到应用时，就开始坑爹了
买票成功，有二道坎，第一坎，登录，它会反复提示了访问用户过多，稍后再试，于是我遵照它的指示不停地试，终于登录成功
第二坎，确认订单，它会反复提示你系统忙，请查看未处理订单后继续，(类似柜员做交易，返回超时，不知道后台记账成功与否，需要做查询后决定后续动作)，于是我遵照它的指示查看未处理订单，但几个回合下来，一直没有未处理的订单，于是我就懒得再去查看了，直接不停地反复提交订单，终于网站提示我由于取消订单过多，取消我当天购票资格，9号再来吧。
太坑爹了，还好我准备了二台电脑和多个账户，经过半个多小时奋战，终于订到票了，不枉我一番苦心，皇天不负有心人啊，一份付出一份回报啊

千问 · 2011-12-22 10:19:42

CountOnMyself 发表于 2012-1-11 20:34
网站操作大部分是属于页面的操作，我觉得压力应该是在WEB服务器上。
网站无法登录，说明了还没进入交易阶段 ...
IBM又可以拿它的大机来忽悠了.......

千问 · 2011-12-22 10:19:42

hppyhjh 发表于 2012-1-11 21:36
从我8号买票的经历来说静态页面的显示还算正常涉及到应用时，就开始坑爹了
买票成功，有二道坎，第一坎， ...
你还真能付出啊！
现在都用外挂买票了！

千问 · 2011-12-22 10:19:42

hppyhjh 发表于 2012-1-11 21:36
从我8号买票的经历来说静态页面的显示还算正常涉及到应用时，就开始坑爹了
买票成功，有二道坎，第一坎， ...
从新闻上看到，平均是500次操作才成功购票一次，证明这么大的操作量其实是因为交易成功率太低导致的，如果可以一次成功，则每天真正的点击量就可以下降到300万次了吧。
所以我认为该系统不仅是没有考虑通过分布式架构实现负载均衡，甚至可能点并发流量控制和任务排队机制都没考虑进去，否则交易成功率不可能这么低。1/500的成功率，太坑爹了。
如果以银行系统而言，交易成功率下降到99%就肯定被骂娘了。
从这点看，这个网上订票系统和银行系统从架构上来说，差距是巨大的。
当然，我也不认为大机方案就一定可行，这只是IBM自已的宣传。从可扩展性看，分布式架构才是最佳解决方案。

千问 · 2011-12-22 10:19:42

老胡感觉各位可能忽略了一个因素，就是电话订票和人工售票，乃至是网络售票，更新的应该是同一个数据库，对数据库的压力是一个不容忽视的因素，每个渠道只是一部分，所以把网络订票系统的性能低劣考虑为单一系统（例如认为是web服务器不给力）可能有失偏颇

千问 · 2011-12-22 10:19:42

这也是铁道部脑袋着地才能出此洋相。要像银行业一样，来个10来个乙方拼杀，肉搏PK，虽然不能杜绝潜规则，但最终方案肯定科学许多。
看新闻，方案商也就3家：IBM、清华的一个研究中心、铁道部自己的电子所。显然竞争不够。

千问 · 2011-12-22 10:19:42

淘宝双12的时候这么多的交易量也没有垮，铁道部应该好好学学人家，要不干脆把售票的职责包给淘宝好了