前言
中国铁道部，3亿RMB。
12306又一次成功地吸引了全国人民的眼球。自然，不同身份的人从中有着各自的解读。
2011年的一波，如今的又一波。可以预计的两个月后还有一波。
做为一个IT从业人员看着很多专业或非专业的评论和分析文章，其实内心也早有自己的想法。毕竟曾经有幸参与过一个小规模的票务系统，虽然小道不起眼，但至少还是接触了不少有关票务的领域知识。
一个人的知识和认识一定比不过一个公司和团队，但是软件创新靠的是点子，不是票子。而好点子是人人都可能想到的，无非因为各自的背景知识以及掌握的需求细节不同而导致提出的解决方案各有差异。不过也正因此，有些意见其实并不是很合理，铁道部和太极公司其实也是有点冤的。
本次争取用国庆的长假把个人对于票务的有关知识整理一下，也能提供给其他对此有兴趣的朋友参考。并提出自己对12306的售票系统乃至更个铁道部整体信息化进程的一个个人观点。
整体博文计划大致如下：
- 12306的已知信息、数据及问题
- 需求分析（一）—— 售票系统领域知识（区间票、订票、预留票）
- 需求分析（二）—— 涉众、用户体验
- 核心业务逻辑架构分析与设计（子系统分析）
- 需求分析（三）—— 票仓
- 票仓设计（一）—— 预生成车票方案的优缺点
- 票仓设计（二）—— 区间二进制方案的优缺点
- 票仓设计（三）—— 平衡方案的优缺点
- 票务并发冲突处理原则设计（基于平衡方案）
- 缓存逻辑架构设计
- 数据库逻辑设计
- 灾难备份与恢复
内容可能有增减，随时调整。 大伙别给吓着，有些东西我也只能YY个大概。希望各位过路的大神能多多指点。
如果真的能为全国人民做件好事也是值得的。
另外，我这里想吐曹大部分的“架构师”，其实他们不是架构师。
如今很多软件企业充斥了“部署师”，而不是架构师。“部署师”们遇到问题后总是通过各种服务器伸缩性来满足性能问题。
当然，大部分情况下（80%-90%），“部署师”们日子很滋润。但是当他们碰上12306的时候怎么办？如何将一个现有架构转换到新架构？如何用最低成本构建满足当前需求的架构？如何保证现有架构的扩展性？
我不知道确切的答案，但我知道多数“部署师”们也不知道答案。
所谓的系统架构,是从软件数据建模,业务建模以及代码建模后产生的一个东西,系统架构绝对不仅仅是"N层架构"，一个垃圾级别的代码架构，光靠增加服务器是会吧财神爷弄破产的。
系统的整体性能来自于每行编码，来自于每段算法设计，来自于部署架构。
什么是12306？
http://tech.it168.com/a2012/0116/1302/000001302844.shtml
12306网站购票业务是2011年6月12日投入，2011年6月12日5时，京津城际高铁开始试行网络售票，2012年年底，全国铁路已经全面推行网络售票，中国铁路开始走进电子商务时代。从2011年6月24日9时起，铁路部门开始对外发售京沪高铁车票。截止2011年12月24日起以“C”、 “D”、“G”、“Z”、“T”、“K”、“L”、“A”、“Y”开头的以及1000至7598的旅客列车都可以采用网络订票，有关事项按《旅客列车互联网售票暂行办法》的有关规定办理。市民购买火车票的方式从只能亲自到火车站售票口或代售点排队购票，逐步发展为可通过电话订票或网站订票。
http://baike.baidu.com/view/3188461.htm
12306是全国铁路统一客服电话号码，12306网是铁道部客户服务官方网站，12306网站提供火车票查询、网上订票、铁路知识和新闻公告、货运信息查询等，其中火车票查询包括12306余票查询、票价查询、火车时刻查询、火车票代售点查询、正晚点查询、中转查询等，其中余票查询信息每10分钟更新一次，但由于查询库数据没更新或车票锁定等原因，会造成余票查询结果不准确，所以余票查询信息只能做参考。
什么是春运？
来源 百度百科：http://baike.baidu.com/view/16644.htm
春运是中国在农历春节前后发生的一种大规模的高交通运输压力的现象。以春节为中心，共40天左右。
“春运”被誉为人类历史上规模最大的、周期性的人类大迁徙。在40天左右的时间里，有30多亿人次的人口流动，占世界人口的1/2，相当于全国人民进行两次大迁移。[1]中国春运入选世界纪录协会世界上最大的周期性运输高峰，创造了多项世界之最、中国之最。口语中的“春运”有两个含义，一是指春节前后的运输现象，二是“春运期间”的简称。春运规模之大，以致中国大陆交通难以承受，为了解决春运问题，中国政府每年都要提前部署，但仍无法满足春运要求。
- 2004年18.9亿人次
- 2005年19亿人次
- 2006年20亿人次
- 2007年21亿人次
- 2008年22亿人次
- 2009年23.2亿人次
- 2010年25.41亿人次
- 2011年28.53亿人次
- 2012年春运从1月8日开始，至2月16日结束，共计40天，春运期间客流量将达31.58亿人次，同比增长9.1%。
当前状况
http://tech.it168.com/a2012/0116/1302/000001302844.shtml
从1月5日起，12306网站连续5天日均点击数超过10亿次，高峰时超过14.09亿次，访问量环比上月激增10余倍。根据专业互联网分析网站Alexa12日发布的统计数据，7天内访问12306网站的用户占全球互联网用户的0.902%。
上午11时18分，大屏幕上显示实时数据：共售出121199张票，登录用户521754个，车票查询2673316次……
“既有互联网接入带宽明显不足，造成网络拥塞，高峰时间段用户访问网站时页面打开缓慢或出现超时报错的情况，影响用户的购票体验。”中国铁道科学研究院常务副院长康熊说。
康熊介绍说，12306互联网购票是基于中国铁路客票系统构建的，历时两年研发成功。去年年底前开通了所有列车的网上购票功能，是目前世界上规模最大的实时交易系统之一。
铁道部信息中心副总工程师李舒扬指出，“由于在系统设计时，对春运期间互联网购票需求估计不足，导致在节前春运售票过程中，互联网售票日交易量超过系统设计能力(最高达到166万笔)时，系统部分时段性能下降，客户体验不佳。”李舒扬承认。
为尽力解决这一问题，铁科院不断扩容12306带宽并加大维护力度。
“从最初的400M带宽，现在已经发展到1.5G带宽，12306网站根据需求正在不断扩容、完善，尽最大努力满足用户需求。”李舒扬说。
自2011年12月28日开始预售春运车票以来，已通过互联网售出997万张，占总售票量11.1%。
康熊表示，目前，铁道部已启动了新一代客票系统的规划和设计，12306互联网售票系统也将基于新一代客票系统进行优化和进一步发展。
收集到的数据
时间跨度：40天
总人次（车票量）：30亿+ （补丁：按大家的思路重新估算为8-16亿）
PV：14亿+/天
估算数据
每个车次平均由17节车厢组成
每节车厢平均额定座位数108人
整个春运共计30亿/17节/108人= 163万车次 （补丁：按大家的思路重新估算为16万车次。 这里我也犯了个错，一个座位可以卖多张票的。所以即使真的是30亿人次，实际的车次也不会有163万。）
网络上大家的各种意见
http://wenku.baidu.com/view/5d7eef3f87c24028905fc305.html
这个是我感觉设计上比较靠谱的一个，当然只是一些核心概念。没有太具体的内容。
http://subject.csdn.net/traindesi/
百度 林仕鼎
摘要：避免性能尖峰出现
4399 曹政（这个哥的方案可能只花了半小时，所以难免有疏漏）
摘要：
存储key-value化, 推荐redis。 每张票对应一个key，一个value(该观点是不符合需求的)
将所有查询结果缓存化，静态化（这个也是不符合需求的观点）
前端缓存处理（靠谱）
云风
摘要：先用了个分流，不过分流后还是买同一张票，感觉没意义。后面提到要关注新老系统的平滑整合。
http://coolshell.cn/articles/6470.html
http://www.zhihu.com/question/20017917
http://www.cnblogs.com/wangzhanjianshe/archive/2012/01/16/2326374.html
http://tieba.baidu.com/p/1367147423
已知问题
一、大数据量
30亿人次坐车，至少就是对应30亿张票。即使考虑到不是一天全进行预售，但是只要也有12天的预售期。估计10亿张票少不了。
其实理论上的“车票”数量远远超过30亿张，十倍都不止。这点会在第二篇博文里立刻向大家介绍。所以，基于春运售票的特点，任何妄图对“车票”进行事先生成或缓存的方案都存在本质缺陷。
“车票”是绝对不可能被缓存的，否则可能3个亿RMB都不够用了。
二、高并发量
买车票就如同“秒杀”。是的，非常像。把线下的实体售票窗口搬到线上，然后说好整点我们一起开卖。呵呵，如果已经有10万个用户登录，那么就是瞬间10万并发。My God！
三、密集查询
要买票就会查，而买本身也是一个查的过程。并且每次查询都是针对一个范围内进行统计。如果一个车次由2000张票，一个人一次查10个车次，就是要比较2万行数据。然后乘以几万乃至几十万在线用户数。
四、业务逻辑整合
整个购票系统的设计还要考虑到各种车票的预留，增加，划转。
可能存在的重大核心问题
铁道部似乎一直对他们内部的一个“核心”非常在意。从每次被质疑的反应来看，他们都倾向于是因为配套网站的带宽，缓存等等问题造成了如今的结果。
其实已经有不少人在各自的方案中体现出大家对现有12306系统架构的质疑。其实它对于查询优化做的不到位，以及业务处理分布不合理才是本质的问题。
我有一些感觉，那就是除非那个核心能支持目前压力规模的几十倍以上，否则一定挂。
具体会在谈到需求的那个时候在来展开讨论。
最后感谢大家路过。
谢谢。
Bug Fixing：
1、重新核实了一下有关车票总量的估算。
原来我上面的30亿+是指全国春运期间的交通部门的总运输量。所以实际落实到铁道部的应该小于30亿。
由于园友爱公司的程序员估算年度20亿张票，因此也就把估算值调整到20亿。
这样一来的话整体车次数量也下降到110万左右。
2、受园友buzzlight的提醒，其实客运列车的编号似乎只有几千个（<8000）。而且按惯例单双号的车次不会一起开。比如K598/599次，不可能同时运行。这样一来，即使每个车次都是一天跑完隔天回来。那么每天跑在路上的也只有4000车次。整个春运40天应该是16万车次而已。
呵呵，这么一来数据量可能就下降接近一个数量级了。后续文章车次估算值就按20万车次计算吧。20万车*2000人/车 = 4亿，考虑座位重用，那么整体车票量可能在8亿-16亿之间。
扫一扫
772
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
