关于火车订票系统瓶颈的分析及解决方案
需求描述
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;同时在线不知道会如何;
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;同时在线不知道会如何;