主题：【原创】无责任推测12306网站遇到的麻烦 -- 代码ABC
家园 另，据我了解到的，Sharding最后 他们还是做了，到一月上旬的时候，系统改成了将热门票和冷门票分开的策略，是从存储端分开的。这样热门票本来也难买，慢点也就慢点了，冷门票就没有这个问题了。
家园 首先从数据库着手更有意义吧 把热点数据与冰点数据从存储物理分离不是很那个啥
即使是这样剥离也应该是热点数据占据最好的资源比如固态硬盘和FC 冰点数据上TB的sata就是了 系统看上去才和谐嘛 符合现正流行的优化
不知道他们用的啥存储？EMC?HDS(HP/SUN)?IBM?也应该就这仨大吧。。。
家园 这都是要求将业务逻辑移出Legacy System。 由于那个Legacy System的局限，目前你说的几种方案都是无法实施的，除非将业务逻辑移出该Legacy System，比如直接跑在JBoss上，那样做HA+LB毫无压力。但这个选择的主要问题在于：
１.工作量太大，这个工作量就是重新做一个购票系统，时间不够用了。你要注意的是，目前这个互联网购票系统其实只是一个壳子，真正的业务部分实际上是在那个Legacy System的，也就是大头的工作是在后端的，并不是前端互联网这块儿。实际上根据该大拿的说法，在１月份时，系统负载最高点跑JBoss/Web那端服务器的ＣＰＵ负载不过1０%。而后面LegacySystem早就完蛋了。
那么把这个业务逻辑重新实现一遍？那就不是几个月能够搞定的事儿了。
２.相比互联网售票，窗口售票系统的稳定性更是大局，如果窗口售票系统崩溃了，那就成了政治事件了。这也是为什么无法冒险在短时间内升级的另一个主要原因了。
我说铁科院这帮哥们儿倒霉就倒霉在团队成立初期按上任部长的思路，只卖高铁票，所以设计了这么个jboss前端+TRS的悲催方案；结果部长一换人，变成了全部票都卖的需求，时间还不够用了（只有三个月）。
当然，换句话说，如果一开始就规划成把ＴＲＳ整体重写一遍，那样项目的投资恐怕翻１０倍都不止。
按现在的情况，如果马云在上面的关系更ＮＢ一点的话，有可能这个系统后面的大改造就给ＴＢ做了，只是一种可能哈。
家园 业务逻辑移出TRS和TBS反而是错误的 现在他是耦合他紧密了，所以前端的峰值压力瞬间压暴了后台应用，我在文中也写了。
家园 技术细节不说，高阻铁定又是问题的根源
家园 据说这个网站在春运期间是日均10亿次的访问量。 家园 我认为是高并发造成的数据库连接数不足导致用户体验差 12306估计没用什么分布式数据库，即使不考虑这个，哪怕一个车次使用一个单独的数据库（跟淘宝似的），一趟车1000个座位，假设同时会有10w人来抢票，啥数据库也得被锁等待弄得贼慢。并发多了之后，你在等我，我在等他，谁都很难动得了，这和一大堆人挤安全门是一样的。数据库处理锁等待的时候，都是占着CPU的，所以一锁就慢，慢了更锁。当有锁很多的时候，CPU很容易被耗尽，更关键的是数据库连接数会更容易被耗尽，Oracle数据库连接数上万也就很多了，和急等着回家的网民比，这点量算啥？所以不断会有人被提示用户数过多
查询的时候不被锁很容易，啥脏读呀、UNDO呀，就是干这个的，但这也都是有代价的。
家园 网站和内部的票务系统有没有连接不好说 窗口售票不受影响不说明12306和内部票务系统没有连接
也可能是压力不在票务系统上面
反而如果没有连接，那说明设计人员很弱智
我们用一个简单的计算
每天7000万人坐车，假定50%是通过12306购票的
那么可以按照每天通过12306卖出3500万张票
而且可以预期的是这些票中的很大一部分都是在刚开始营业的10分钟内卖出去的，假定是1000万张
那么12306在10分钟内要进行1000万次交易（不含查询/登陆）
1000万/10/60=16666TPS
这还没有考虑峰值压力，这个数字很可怕
又有新闻说12306硬件采购1000多万元
假定都是应用服务器，可能也就100台
已经做的很好了，他们的问题在于业务，不见得是技术
（这个断言是从我的经验来看，我做的系统设计目标只有4000TPS，当然实际上可能能超过8000）
业务上来说，12306应该24小时营业
还有一些规则可以变更，
例如说提前7天可以购票，现在的规定是旅行日期之前7天就可以买
那么大家都拥堵在开始营业的那几分钟
如果改成列车开车时间前7*24小时开始售票
可以将压力均分，就会好得多
家园 12306每天只卖100万张票 只是比电话售票多一点而已。所以这个系统并不怎么样。
家园 能普及一下铁道部这个网站大体是何种水平吗 网上看的图片。
外链图片需谨慎，可能会被源头改这个大约是在何种水平？10万人在线，每秒20笔支付。
应该不会超过淘宝京东之类的一流电商网站吧？和民航订票系统比呢。
家园 就人数而言算是一个大规模的网站 每秒20笔支付其实很少很少——只相当于一个普通的网站而已。
但是10万人在线就人数而言算是一个大规模的网站。
我有一个经验数值，如果你的系统满负荷下可以应付每秒N次请求，那么也可以应付峰值每秒2xN次请求。原因是一般用户可以接受高峰期3-5秒的延迟。超过这个时间用户就会失去耐心，并且开始”不理智“地刷新页面，把系统进一步推向崩溃。不同网站这个系数会有差别，看用户的耐心程度，可以取2-5。
就10万人在线这个数据，我们假设平均思考时间是5秒。那么平均每秒有2万次查询。一般耐心的用户我们可以在大致每秒一万的系统设计能力下满足这个需求而不会出大事。能达到这个级别的处理能力才算得上大规模网站。所以12306在设计能力上还不算。