关于火车订票系统瓶颈的分析
- - ITeye博客1.根据新闻发布的数据，每年春运的运送旅客人次在31亿人次，基本分布在40天时间内. 2.依然提前10天买票，所以这么算每天最多在1亿人次(新闻说最多7kw每天依然做坏打算). 3.假设每个人只自己买票，或者每个票都需要实名认证(最坏的统计). 4.每天会有1亿的业务查询(身份证验证),每天会有1亿的交易(支付).
关于火车订票系统瓶颈的分析
标签：
火车
系统
瓶颈
| 发表时间：2012-01-09 09:12 | 作者：
出处：http://www.iteye.com
需求描述
1.网站订票
2.身份证实名验证
思考
1.根据新闻发布的数据，每年春运的运送旅客人次在31亿人次，基本分布在40天时间内
2.依然提前10天买票，所以这么算每天最多在1亿人次(新闻说最多7kw每天依然做坏打算)
3.假设每个人只自己买票，或者每个票都需要实名认证(最坏的统计)
4.每天会有1亿的业务查询(身份证验证),每天会有1亿的交易(支付)
5.每天最多一个亿的数据库订票记录，一个亿的数据库insert操作
问题瓶颈(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.身份证第三方只要支持每秒1w＋的并发请求就足以支持订票了。很容易
4.如果本地验证身份证，根据省份、建立表，根据城市建立分区表，速度也会非常快，用身份证做主键，一条身份证信息0.2k，全国13亿＝260G的数据量，easy，做个RAC就足以支持这种压力了
5.银行不考虑
6.车次，订票记录，余票记录，每天7kw的记录，14G/天，保存20天，才280G
7.订票业务按照省份分布，每个省份单独结算
8.整体采用SOA架构，都是服务，每个服务专注自己的业务，优化自己的服务
9.银行交易需要大量校对和核实业务，也许要一些投入，算成本
想不明白他们是怎么设计的，性能会这么烂
给我5个1000M光纤接入，5箱刀片，基本就可以解决这个service了吧。。
200W的硬件投资，600W的软件开发，200W的技术支持和服务
1000W一个solution，不知道这个东西他们实际投资了多少钱，1000W是我的报价，拍拍脑袋，很多软件，硬件方案，网络拓扑，都没细化，估计也是个赔本的项目＝ ＝。
很多数据全凭臆想，可能很多不符事实，疏漏很多，考虑不全
不过还挺好玩的。
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
1.网站订票
2.身份证实名验证
思考
1.根据新闻发布的数据，每年春运的运送旅客人次在31亿人次，基本分布在40天时间内
2.依然提前10天买票，所以这么算每天最多在1亿人次(新闻说最多7kw每天依然做坏打算)
3.假设每个人只自己买票，或者每个票都需要实名认证(最坏的统计)
4.每天会有1亿的业务查询(身份证验证),每天会有1亿的交易(支付)
5.每天最多一个亿的数据库订票记录，一个亿的数据库insert操作
问题瓶颈(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.身份证第三方只要支持每秒1w＋的并发请求就足以支持订票了。很容易
4.如果本地验证身份证，根据省份、建立表，根据城市建立分区表，速度也会非常快，用身份证做主键，一条身份证信息0.2k，全国13亿＝260G的数据量，easy，做个RAC就足以支持这种压力了
5.银行不考虑
6.车次，订票记录，余票记录，每天7kw的记录，14G/天，保存20天，才280G
7.订票业务按照省份分布，每个省份单独结算
8.整体采用SOA架构，都是服务，每个服务专注自己的业务，优化自己的服务
9.银行交易需要大量校对和核实业务，也许要一些投入，算成本
想不明白他们是怎么设计的，性能会这么烂
给我5个1000M光纤接入，5箱刀片，基本就可以解决这个service了吧。。
200W的硬件投资，600W的软件开发，200W的技术支持和服务
1000W一个solution，不知道这个东西他们实际投资了多少钱，1000W是我的报价，拍拍脑袋，很多软件，硬件方案，网络拓扑，都没细化，估计也是个赔本的项目＝ ＝。
很多数据全凭臆想，可能很多不符事实，疏漏很多，考虑不全
不过还挺好玩的。
已有 0 人发表留言，猛击->> 这里<<-参与讨论
ITeye推荐
相关 [火车 系统 瓶颈] 推荐：
软件开发中常见的十大系统瓶颈[转载]
- - CSDN博客推荐文章在 Zen And The Art Of Scaling - A Koan And Epigram Approach中， Russell
Sullivan提出了一个非常有趣的总结：软件开发常见的20个传统的系统瓶颈，这听起来像是说有 20个故事情节，并且依赖于你如何策划这些故事，或许都是真的，但唯有实践才知道它们带给我们的酸甜苦辣.
理解Linux操作系统——分析性能瓶颈
- - 小火箭通过每次只修改一个地方来解决瓶颈问题. 回到第3步直到对系统的性能满意为止. 应该记录下调优的操作，特别是对性能有影响的操作. 通常，你能得到的第一手信息就是关于问题的描述. 对问题进行探索性地提问和记录是非常重要的. 这里有一些问题有助于你对系统有一个更好的了解：. 服务器系统类型、版本、配置是什么.
12306火车订票系统漏洞
- - 蓝飞技术部落格摘要：铁道部旗下在线购票网站12306自诞生起就一直为人所诟病，网站经常崩溃、UI粗糙、漏洞满框，但这都不是什么新闻了，近日网友爆出12306的技术框架及其表结构，大家可以来一览究竟. 应用服务器：WebLogic. 开发框架：Spring\Hibernate\Struts. 这里可以看到完整的SQL语句：.
JVM 性能调优实战之：一次系统性能瓶颈的寻找过程
- - ImportNew玩过性能优化的朋友都清楚，性能优化的关键并不在于怎么进行优化，而在于怎么找到当前系统的性能瓶颈. 性能优化分为好几个层次，比如系统层次、算法层次、代码层次…JVM 的性能优化被认为是底层优化，门槛较高，精通这种技能的人比较少. 笔者呆过几家技术力量不算弱的公司，每个公司内部真正能够进行 JVM 性能调优的人寥寥无几、甚至没有.
【图集】世界上最危险的火车系统
- 林子 - 译言-每日精品译文推荐来源IN PICTURES: The World\'s Most Dangerous Train System. 根据法国新闻社的报道，每年约有25000人死于印度的铁路上. 在这些遇难者中，许多人都死于火车事故，剩下的多数则死于摔出车门或者在轨道上被撞. 在火车高速奔驰的时刻，在火车的第一节车厢或一般得隔间里是一场噩梦，那里的每一寸地方都爬满了上下班的人.
建设一个靠谱的火车票网上订购系统
- - 爱范儿 · Beats of Bits昨天，2012年1月11日，网友 @fenng 写了一篇文章，批评铁道部火车票网上订购系统，http://www.12306.cn [1]. 同时在新浪发了一条言辞激烈的微博，“去你妈的‘海量事务高速处理系统’”，引起热议 [2]. 春节将到，大家买不着车票，赶不上大年三十与家人团聚，急切心情可以理解.
简单讨论火车票系统后面的架构设计
- - 酷勤网-挖经验 [expanded by feedex.net] 来源：51CTO技术博客 2012-01-16. 简单说，在线服务scalability有两种方式，scale-up和scale-out. Scale-up追求单机性能，如高级硬件、异步架构等，而scale-out则用加机器的方法. Scale-out也是最简单的方法，在规模不是非常大时很好用，也很容易解决问题，普通工程师就足以胜任.
我的瓶颈在哪里？
- 弛 - 博客园-首页原创精华区 最近在处理一些比较复杂的问题，在解决这个问题的同时，我深刻的体会到，问题的本身，对我来讲，并不是最重要或者最紧要的（当我解决掉一个问题，其结果也只是问题不存在了）. 我认为是我的思维能力或者思维方式，用最优质的方法去解决问题，这才是王道. 在平平淡淡的生活中，我们会碰到大量的问题，有的问题 凭直觉就能解决，如果碰到稍微复杂的问题，我们就不知道从什么地方入手，也就是我们找不到解决问题的方法，或者叫切入点.
常见的10种“瓶颈”
- - CSDN博客推荐文章Working size超过可用内存. Working Size怎么理解. 肯定不是指数据库的大小，应该是在保证业务指标——响应时间、QPS的情况下，数据库使用的内存大小. 其超过可用内存后的直接影响就是系统开始使用“swap”，从而大大降低DB的性能. 所以，DB服务器要有充足的内存. 运行时间很长的查询，要是么很消耗内存、CPU，比如联合查询，要么是很消耗磁盘I/O，比如没有用到索引的“遍历”——这应该算是“事故”.