关于火车订票系统瓶颈的分析及解决方案

需求描述
1.网站订票
2.身份证实名验证

思考
1.根据新闻发布的数据，每年春运的运送旅客人次在31亿人次，基本分布在40天时间内
2.依然提前10天买票，所以这么算每天最多在1亿人次(新闻说最多7kw每天依然做坏打算)
3.假设每个人只自己买票，或者每个票都需要实名认证(最坏的统计)
4.每天会有1亿的业务查询(身份证验证),每天会有1亿的交易(支付)
5.每天最多一个亿的数据库订票记录，一个亿的数据库insert操作
6.补充，最新新闻说一天点击10亿次。= =！这个量级。。

问题瓶颈(Front to Backgroud)
1.Web端，每天请求上亿，压力很大，包括html js css img等，需要占用大量带宽
2.身份证认证，可能会用到第三方的认证，或者铁道部协议，获取到身份证信息，这个查询量也很大
3.交易，银行性能应该不在瓶颈
4.订票记录，采用按照车次分表，应该是集中控制集群，分表 分区 索引，速度不会太慢
5.查询余票,每次交易成功，更新订票数据，更新量较大

分析
1.网站的内容可以分布式部署，采用apache＋xxx分发，后台多个镜像分担请求，进行冗余;图片、css、js、html、动态jsp、后台业务，分别部署;并且对web进行部分优化，压缩，合并，缓存等。
2.每次订票数据流量在2M，每天1200w/8h/60min/60s，每秒420个订票请求，840M/s的网络流量，根据分布6种文件140M/s，一般光纤网络就可以了;每种文件下面分布几个cluster，性能足以支持，每秒70个请求。并不大
3.身份证第三方只要支持每秒1k＋的并发请求就足以支持订票了。很容易
4.如果本地验证身份证，根据省份、建立表，根据城市建立分区表，速度也会非常快，用身份证做主键，一条身份证信息0.2k，全国13亿＝260G的数据量，easy，做个RAC就足以支持这种压力了
5.银行不考虑
6.车次，订票记录，余票记录，每天7kw的记录，14G/天，保存20天，才280G
7.订票业务按照省份分布，每个省份单独结算
8.整体采用SOA架构，都是服务，每个服务专注自己的业务，优化自己的服务
9.银行交易需要大量校对和核实业务，也许要一些投入，算成本;需要对仗，异常情况分析等，属于不是直接业务的处理，不能省略。
10.硬件IO，视情况而定优化，EMC盘阵，RAID;数据分布存储，根据数据量划分group。
12.CPU，内存通过简单增加刀的CPU和内存来提高。
13.网络，根据地点，业务分布到不同的节点进行购票，每个节点的网络吞吐可以控制，不会太高


想不明白他们是怎么设计的，性能会这么烂
给我5个100M光纤接入，5箱刀片，部分盘阵，基本就可以解决这个service了吧。。
200W的硬件投资，600W的软件开发，200W的技术支持和服务
1000W一个solution，不知道这个东西他们实际投资了多少钱，1000W是我的报价，拍拍脑袋，很多软件，硬件方案，网络拓扑，都没细化，估计也是个赔本的项目＝ ＝。
1000w，相当于100米高铁的费用，解决全国人民的买票难问题，我觉得划算。



很多数据全凭臆想，可能很多不符事实，疏漏很多，考虑不全
不过还挺好玩的。 

----------------
最新消息
在线访问人数最大500w左右 ＝ ＝！超过baidu空间
并发量达到1GB
银联支付也是一个瓶颈，银联支付慢，导致问题

----------------
并发500W，必须得分布了，按照省份分布吧。
目前只用银联支付，建议增加支付保等第三方的支付渠道，以及其他类似支付保的支付服务。
个人觉得最主要还是得SOA的架构，规划好服务，彼此独立，单独优化，更好部署一点。
现在看500w的在线用户数，可能200w的硬件投资拿不下来，还是得从业务上调整一下，尽量避免无用的重复性的访问，增加静态缓存，减少session占用的资源，减少交易在线时长，能有效减少在线用户数，避免多人用同一个身份证号刷飘，进行多次校验，使得最后落入实际交易服务的请求数尽量减少，类似缓存，一层一层的命中，一层一层过滤拦截;
另外火车票放票也得控制一下，可以分省份放票，利用所有的计算能力，服务单独省份的瞬时并发请求。

----
做过单台T2000，1000＋并发，0.2s响应时长;瓶颈在网络。
如果加大响应宽容度，估计一台普通T2000机架支持个5000左右没问题吧。只是并发请求，不是保存session;同时在线不知道会如何;

评论

11 楼 wangshu3000 2012-01-10  

dcdc723 写道

基本的系统设计都没有，就随便搭了一下网站就以为可以应付了事。祸害了老百姓啊。连小学生都知道的异步你至少得有吧，压力测试应该敢没有做，压力分发就更没有了，数据库直连的方式还处于小学阶段，不用提改进建议了，他们不知道是什么的。。浪费时间跟表情。

感觉他们还是有架构设计的，要不然可能早就404摊了，估计设计容量没支持到500w的在线，10亿＋的日访问量。。

10 楼 wangshu3000 2012-01-10  

yexingren23 写道

博主对12306订票系统设计的技术分析得很清楚。

我这里补充一下用户的操作行为分析，现在网站出现的大量问题表明对用户的操作行为分析不到位。

客户特点：运力不足的现状导致：用户饥饿抢票，登陆不见去，我就不断地刷新页面，直到发现票已售完，一个人登陆不进去，就会发动10个亲朋好友一起帮助点击抢票，不怕买多了，就怕买不到；

详见我的博客：《让你设计12306网站》
http://yexingren23.iteye.com/admin/blogs/1336844

赞，优化业务流程也是很重要一环，架构包括技术架构，业务架构，物理架构，软件架构等各种层面，看样子是他们业务层没规划好。。

9 楼 dcdc723 2012-01-09  

基本的系统设计都没有，就随便搭了一下网站就以为可以应付了事。祸害了老百姓啊。连小学生都知道的异步你至少得有吧，压力测试应该敢没有做，压力分发就更没有了，数据库直连的方式还处于小学阶段，不用提改进建议了，他们不知道是什么的。。浪费时间跟表情。

8 楼 yexingren23 2012-01-09  

博主对12306订票系统设计的技术分析得很清楚。

我这里补充一下用户的操作行为分析，现在网站出现的大量问题表明对用户的操作行为分析不到位。

客户特点：运力不足的现状导致：用户饥饿抢票，登陆不见去，我就不断地刷新页面，直到发现票已售完，一个人登陆不进去，就会发动10个亲朋好友一起帮助点击抢票，不怕买多了，就怕买不到；

详见我的博客：《让你设计12306网站》
http://yexingren23.iteye.com/admin/blogs/1336844

7 楼 wangshu3000 2012-01-09  

lyrss 写道

博主应该是很牛的，我想做个类似中国化肥网的http://www.huafei888.com/平台，考虑用java结合php做，以后主要考虑手机终端访问及在线办公，请博主给点建议？

一般流量不太大的话可应用开源CMS，改个模板就行了。。

6 楼 wangshu3000 2012-01-09  

houxinyou 写道

你算的成本是1KW,也许路道部出的钱远比这个高,但是,真正干活的,也许连你算的成本的十分之一都没收到!这种活,扒皮的人很多的!

在这个网站上不谈那些东西。。

5 楼 wangshu3000 2012-01-09  

hzw2312 写道

国企项目、不是你有能力、想做就做得了的！

谈技术。。谈技术。。。

4 楼 wangshu3000 2012-01-09  

lyrss 写道

博主应该是很牛的，我想做个类似中国化肥网的http://www.huafei888.com/平台，考虑用java结合php做，以后主要考虑手机终端访问及在线办公，请博主给点建议？

java结合php？我也没啥建议，就是web网站的设计和优化，可以参考javaeye的吧。有本书专门讲web网站的高性能设计的。
手机终端可以wap或者app。没了。。

3 楼 houxinyou 2012-01-09  

你算的成本是1KW,也许路道部出的钱远比这个高,但是,真正干活的,也许连你算的成本的十分之一都没收到!这种活,扒皮的人很多的!

2 楼 lyrss 2012-01-09  

博主应该是很牛的，我想做个类似中国化肥网的http://www.huafei888.com/平台，考虑用java结合php做，以后主要考虑手机终端访问及在线办公，请博主给点建议？

1 楼 hzw2312 2012-01-09  

国企项目、不是你有能力、想做就做得了的！