社区专家谈 12306

url:http://www.iteye.com/magazines/110

由于春运，铁道部官方订票网站12306流量暴增，其Alexa排名一度进入前200，网友戏称，12306已经成为“全球最大、最牛的电商网站”。由于流量激增，12306系统频频瘫痪，一度出现登不上去、登上去抢不了票、抢到票需排队、排队后出票失败等局面。系统的用户体验、性能遭到用户大量的不满。

我们邀请了几位系统架构方面的专家，请他们从技术的角度为你剖析12306（我们会陆续增加其他几位专家的回复）。同时我们还从论坛活动（畅聊12306，赢精美礼品）中选取了一些精彩回复。如果您对这些问题有独到的见解，欢迎在本文中评论或参与论坛讨论。

目 录 [ - ]
您是否在春节/国庆期间在12306上买过票？谈谈该系统的用户体验！
12306在去年国庆之前进行了改版，加入了排队系统，您认为加入排队系统的目的是什么？缓解了哪些问题？
12306春运购票，与淘宝、天猫在双11期间的促销有什么异同之处？
淘宝、天猫是如何应对这种超大规模并发的？如何hold住暴增的流量？
您认为这些经验中哪些可以应用到12306？
12306在系统、业务设计上，还存在哪些挑战？
您认为高性能并发系统架构应该如何设计？关键是什么？
有人提议12306采用NoSQL存储，您认为是否可行？
12306 如果使用开源来实现，您有什么建议？
从目前来看，您认为12306需要着重改善哪些方面？如果让您来设计，您会如何做？
庄表伟：与12306相关的一些思考
其他
您是否在春节/国庆期间在12306上买过票？谈谈该系统的用户体验！


范凯   写道
春运和国庆期间没有买过。但去年夏天在12306上面买过票，结果没有买到票，改买了飞机票。

我只用过一次，体验不深。感觉系统不太稳定，我访问的时候看到过Java出错抛出的错误堆栈信息。


陈雄华   写道
有。界面很象是企业MIS，显得很粗糙，交互性，体验性都感觉很次。


runfriends（来自论坛回复） 写道
我知道它很难用，所以我从来没用它买过票。去年国庆节查询个票，慢的要命。

从sql的拼写到页面优化，从程序架构到服务器架构都需要全面重构。居然不是参数化查询sql，而是查询参数拼到sql里的，完全是一群业余选手的习作。 

应该采用js、css、图片、html都应该启用gzip压缩，所有css应减少到一个，js文件该合并的合并，能重用的重用，页面背景图应尽量合并成一个文件。尽量减少http请求数。
12306在去年国庆之前进行了改版，加入了排队系统，您认为加入排队系统的目的是什么？缓解了哪些问题？


范凯    写道
对具体情况我不太了解。我猜测，实时购票是一个高并发的在线事务处理系统，需要通过排队系统来缓解事务并发造成的锁定吧。


陈雄华    写道
排队是缓解资源并发的一次不错的策略，可以在后端资源不足时，将客户端请求暂存在池中，方便系统资源的调度。


runfriends（来自论坛回复） 写道
刚开始的时候看到网上很多人说它有一个巨大的事务。后来又加入了排队系统。至于为什么个人猜测可能是为了降低数据库压力。

而实际上，用户并发量并没有变化，排队导致大量访问不能尽快返回，占用了大量系统资源。实际上这样做降低了系统吞吐量。数据库压力有没有降低先不说，系统吞吐量肯定会降低。


czwlucky（来自论坛回复） 写道
我认为增加这个功能的意义在于，当你不能立即买上票时，不用再不停的反复刷新提交了，相当于银行里发给你一个“号码”，等叫你时你过来买票就是了，不用站那儿傻等。一方面增强了用户体验感，另一方面也能节约反复请求带来的压力。

但我认为买票难根本原因不在于这个，12306网站的压力自然是大的，但这表面的背后却隐藏着更多的问题，为什么一票难求？ 我们问自己一个问题：究竟一列火车有多少张票可卖？ 你会发现没有答案！ 如果真的没有答案，那即便你把12306刷到爆，也无济于事。

所以我认为，在系统设计上不是问题，像淘宝、天猫一样有大量的访问者，解决方案也不是就一个。 问题还是在于业务的设计上，只有把出票规则定合理了，系统才能更好的为大家服务，我们也不用去刷网站了，压力自然也会因此而小一些。

无论是从新闻上了解的，还是我亲身经历的，都证明从始点站开始买票会相对容易些，因为开始出票时，票数还是较多的（虽然也不是很多，大家都似懂非懂的），但从中间站点开始买票，票数少的可怜，甚至是０（网络延迟造成的）。这里面有一个二次售票的概念，怎么把这个二次售票的问题解决了才可能改善购票难问题。

二次售票我相信有它存在的理由。 但问题时它存在的理由真的注定它只能是现在这样的方式存在吗？ 我也相信这个业务规则一定有改进的地方。

公交车，火车，长途汽车，在售票方式与运输距离，输送量上有很大差别，但运输本质没有差异。我们是不是能参考公交运输中的一些优点呢？比如是不是有可能增加同一线路的车次？ 如果不能增加车次，是不是可以考虑沿途换乘方案？
12306春运购票，与淘宝、天猫在双11期间的促销有什么异同之处？

范凯    写道
相同之处应该都是高并发的在线事务处理系统，我猜测主要不同之处在于12306背后的票务系统可能不是一个集中式的系统，而可能连接各个铁路局票务系统，数据同步的实时性和一致性可能更复杂一些。当然这些都仅仅是猜测，可能很不靠谱。


陈雄华    写道
淘宝一天就处理了1亿零580万，而12306一天处理的交易仅仅166万条 ，如果从并发性上来说，淘宝的并发量远比12306大，但天猫的商品信息，促销数据都可以做缓存，做CDN，而12306的“商品”是一个个座位，这些座位必须通过后端数据库即时查询出来，状态的一致性要求很高。

从这点上看，12306的商品信息很难利用到缓存，因此12306查看“商品”的代价是比较大的，涉及到一系列的后端数据库操作，从这个角度讲，12306的复杂度是高于天猫的。
淘宝、天猫是如何应对这种超大规模并发的？如何hold住暴增的流量？

范凯    写道
这个我确实不知道，需要请阿里系的专家来解读。

（小编：阿里专家正在路上，Coming Soon！敬请期待！）


陈雄华    写道
这是一个系统性的功能，简而言之就是：分布式和缓存。
您认为这些经验中哪些可以应用到12306？

范凯    写道
据我个人了解的八卦，去年春运12306宕机之后，曾经求教过阿里，当时阿里派出了一支技术团队去了解情况和提供建议。 实事求是的说，12306相比一年前还是有所进步的，不知道是不是背后有阿里系专家的贡献。


陈雄华    写道
参见第7条。
12306在系统、业务设计上，还存在哪些挑战？

范凯    写道
我觉得12306面临的主要挑战就是两个方面：

一、实时高并发在线事务处理；
二、如何和各个铁路分局票务系统对接，保证数据同步的实时性和一致性。

陈雄华    写道
淘宝的商品相对独立，而12306商品之间的关联性很大，由于CAP定律限制，如果其商品的一致性要求过高，必然对可用性和分区容错性造成影响。

因此，业务设计上，如果找到一条降低一致性要求时，还能保证业务的正确性的业务分拆之路。举个例子，火车票查询时，不要显示多少张，而是显示“有”或“无”，或者显示>100张，50~100,小于50等，这样就可以减小状态的更新频率，充分使用缓存数据。


czwlucky（来自论坛回复） 写道
12306网站的技术问题或许有多种解决方案（虽然可能并不完美），但最难解决的是业务问题！

一列火车总共有多少张票？恐怕这个就难回答，即使是铁道上的人也不见得能回答的十分清楚。

火车跟公交有几分相似，都有固定站点，每个站点都可能有人上下。不同的是，公交车可以先上车后买票，火车只能先买票后上车。我想这才是问题的根本。公交上去了就上去了，上不去可以等下一趟。火车得先有票才能上车，可是卖票规则却成了难解之题。
您认为高性能并发系统架构应该如何设计？关键是什么？

范凯    写道
高性能并发系统其实分很多种类，是并发读，并发写，并发长连接，还是并发事务？不同类型的架构设计是不同的。具体到12306就是并发事务，在这个领域，我个人没有什么经验。


陈雄华    写道
1)  优化前端网页

充分利用CDN，使JS、图片等静态资源的请求能够就近访问（顺便说一下，如果12306订票插件能从google提供的http://cdnjs.com中引用JS，而不去直接引用github的JS，就不会把github搞瘫了）。
将JS、CSS合并，最小化请求数。将JS和CSS压缩，最小化数据传输
启用gzip压缩网页。

2)  群集分发和调度

据说12306是采用集中式构架的，集中式构架很难应对高并发，也很难水平扩容，分布式不是仅仅将调度服务器，应用服务器，缓存服务器，数据库服务器分开就行，应该进行更细的服务级划分，对业务进行服务细分，做成一个个松散耦合的服务，然后把这些服务独立分布式部署。

3)  采用分布式会话

为了可以进行灵活的请求调度，不应采用weblogic、websphere这些应用服务器自身的session管理用户会话，而应该自己管理会话，如将会话保存在独立的集群memcached服务器中，这样每个应用服务就都无状态了，会话的请求可以随意分发给不同的服务器。这也是我的ROP开源项目没有使用HttpSession，而专门抽象出一个SessionManager接口的原因，开发者应该自己去实现这个接口实现分布式会话管理。

4)  关于数据库设计优化

数据库往往是系统瓶颈所在，首先应该对数据库进行分库设计，可采用两级水平切割，如首先切割成几个物理库，然后在物理库内部再采用表分割，一般是通过某个业务ID进行取模切割，降低单库及单表的并发性，提高TPS。

合理采用读写分离技术，做到读写分离，可以一写多读，有效降低数据库的负载，数据的同步可以视情况采取应用层同步写，读取数据库日志更新或直接使用mysql读写分离技术等。

此外，业务服务化、服务解耦化是关键。


runfriends（来自论坛回复） 写道
个人认为针对不同的系统要有不同的设计方案。

虽然12306可以归类为电商领域，但是跟通常意义上的B2C还是有巨大的差异。所以单纯从12306上面讨论高性能并发系统架构并没有通用意义。

不过，有一个思想应该贯彻。那就是所有访问力求分散到不同的服务器处理，不同类型的资源要坚持使用不同的集群服务。动静分离、读写分离，减少一次页面访问的请求数和数据库访问次数，保持小事务粒度，注意线程安全，避免大数据量的查询，建立索引（多表联合、union、非参数化sql、笛卡儿积计算、返回大数据集等数据库操作应该避免）。

对于变化较小的查询操作可将查询工作交给专门的索引服务器完成。不过个人感觉像12306这样的业务，引入索引的意义不大也没有必要。

12306的业务需求乍一看似乎都是同一类型的资源，但是我们可能根据车次、卧、软、硬、站、时段、线路等信息将车票这个12306要处理的惟一类型的资源分成若干子类，不同的子类请求由不同的集群处理。
有人提议12306采用NoSQL存储，您认为是否可行？

范凯    写道
NoSQL的优势在于海量无模式数据存储和查询，12306的挑战在于并发事务处理，所以用NoSQL无助于解决12306面临的问题。


陈雄华    写道
纯用NoSQL个人认为现在还不成熟，毕竟NoSQL的状态一致性不好。一条可行的路子是MySQL+NoSQL，通过nosql缓解后端MySQL的压力。

当然这涉及到很多业务流程的优化设计，降低数据一致性要求后才能合理使用NoSQL。


runfriends（来自论坛回复） 写道
事务的粒度应做到购买行为是原子性的，即保证两个人不会买到相同的票即可。每个票种的优先级是一样的，应不同的查询条件保证能尽快的返回。

实际上每天出售的票种总和远达不到海量的程度。但是每年有几个时段并发量特别大。如果使用大量nosql数据库集群，票量一致性恐怕难以保证；如果使用单台nosql，恐怕吞吐量和实时响应也会像mysql一样难以做到。

不论什么数据库，都难以完成这么少的数据量却要完成这么大并发量的情况。

个人认为还是把不同票种分散在不同票池服务器中，完全由程序操作内存完成查询和购买更合适一些，虽然数据结构可能要复杂很多。

最后根据每个票种的余票量要限制每个票种的查询和购买并发量。超过的就拒绝访问，以节省资源。早死早超生，而不是所有人都耗在买票这个事上。
12306 如果使用开源来实现，您有什么建议？

范凯    写道
其实用WebLogic应用服务器，Oracle数据库，SSH框架和C3P0连接池都是OK的，但要解决12306面临的并发事务问题，需要系统在基础设施和架构上做很多专门的调整和开发的工作，  这些才是解决问题的关键，和用什么软件和框架关系不大。


陈雄华    写道
预算很大一部分都要来买weblogic、oracle的授权了，好钢用在了刀背上。完全可以用jboss代替weblogic，用mysql代替oracle，把这些省下的钱请技术专家，远比买这些东西好用。

另外，这种高并发的互联网的应用不建议使用Hibernate，建议直接使用Spring JDBC，毕竟Hibernater操作数据库往往不够细粒度。另外还建议使用Spring MVC替代Struts，Spring MVC比Struts更高效性，页面尽量使用客户端的技术而不要使用服务端的技术实现，如使用客户端的requirejs+underscore客户端模块就比使用服务端的JSP或Freemarker要好，毕竟这样就让客户机来负责页面渲染了，且可以有效地使用CDN。
从目前来看，您认为12306需要着重改善哪些方面？如果让您来设计，您会如何做？

范凯    写道
12306从前端页面上来看用户体验就比较差，至少从页面设计和前端JS代码上来说就有巨大的改进空间了。后台架构上需要解决高并发事务处理，和分布式数据同步的实时性和一致性问题，在这两个问题上，我个人也没有太多相关实践经验，有一些个人的想法，但还是不误人子弟了，这些方面可以请阿里系的专家来解答。


陈雄华    写道
web前端要大笔优化，采用requirejs+jquery+backbone+underscore框架，web应用要进行部署优化js合并，js压缩；
所有业务SOA化，以便可以将业务分布式部署；
数据库分库，二级切分,实现读写分离，从业务流程调整上降低对数据一致性的要求；
充分使用nosql技术，通过流程优化和调整，使nosql承担大量的数据访问请求，使nosql成为保卫后端mysql的一道坚强的保障。


runfriends（来自论坛回复） 写道
铁道部应该对每节车厢、每个车次要卖出多少站票、软座、硬座、卧铺有一个规划。购买同一车次和票种的人不会造成太高的并发。因此关键在于查询和买票服务器集群的设计和实现。

设计一个票池系统，按照车次、线路、区域划分票池，按照车次、站、软、硬、卧分类不同票种，将每个票种分配到票池集群的某台服务器上。买票时肯定已经确定了票种，通过一致性哈希准确定位指定票种所在的服务器。票池系统完全采用内存储存预售票票种、票量信息。

查询、购买分开不同的集群，两个集群之间实现余票量同步。保证每个操作迅速返回，不必保证查询和购买实时同步，也不必保证查到的票在购买的时候一定能买到。
庄表伟：与12306相关的一些思考

铁路购票的12306网站，我也在上面购买过火车票，虽然的确存在着各种各样的问题，但是最终确实成功的买到了票，而且也顺利的坐上了火车。也许因为不是在春运期间购买的缘故，说实话，我对它的印象没有那么糟糕。

当然，如果我们看看网络上的新闻，搜索微博里的各种人对12306的批评、责骂与嘲讽...是的，他们做得糟透了。
但是，在我看来，痛骂他们的技术如何垃圾，并没有追踪到问题的本质，本文试着继续深入的追究下去。

一、不要外包

分布式系统的第一原则是：不要分布式！而外包系统的第一原则是：不要外包！前一句，有很多高人说过，后面这一句，是我杜撰的。而我之所以会提到这个问题，是因为网络上有很多类似的观点，似乎是因为这次的外包开发没有找好，如果将这个活包给淘宝、支付包、京东、亚马逊之类的大型成熟电商来做，就万事大吉了。事实上，这些成熟电商之所以成熟，恰恰是经过了长期的改进完善之后的结果，而且，一定是他们自己的开发团队完成的。另一个近在眼前的例子，想想苏宁易购吧。直接一点说，如果这事外包给淘宝来做，就算淘宝有人有时间也愿意接这个活，也肯定干不好。

为什么外包通常搞不好呢？因为他们不是自己人，他们没有跟着一个企业同步成长的体会。因为他们希望获得整理明白后的一本“需求汇总”，他们害怕反复不断变动的需求。当然，我这个观点，可能存在着某种偏见，但是，越是变动复杂，极其核心，影响巨大的系统，我都强烈的不建议交给外包来完成。

二、循序渐进

一个非常庞大的电商网站，都不是一天建成的，淘宝不是一天建成的，亚马逊、京东也不是一天建成的。我们怎么能够希望12306在第一次推出的时候，就能够支撑春运购票这样变态的需求呢？

为了限制需求，其实可以有很多种办法：比如限制特定的班次（只卖高铁票、卧铺票、只卖从起点到终点的票等等）、比如网络购票加价，比如只在平时提供使用而不是在春运期间投入使用。总之，不需要一开始就服务所有的用户，选定一个较小的范围，先服务好，再循序渐进，逐步扩大服务的范围、提升服务的效率与质量，才是较为稳妥的办法。

三、排队系统

在12306网站推出之前，我们的购票体验同样糟糕，客观的说，只怕更糟。但是为什么反而没有什么人来骂呢？很多人在说，因为12306的用户体验做得不够好，但是我想要反其道而谈之。如果网站的用户体验能够像当初的实际购票一样差，只怕反而更加好一些。

回顾一下传统的购票流程吧：来到购票大厅，首先要选择一个窗口排队，运气不好的时候，自己选择的那一队恰恰是最慢的。经过几个小时甚至十几个小时的排队，我们来到了窗口前，遇到的是心烦意乱的售票员大妈，她们通常态度恶劣却动作迅速，到哪里？没有！卖完了！只有站票了，要不要？不要就换下一个！看清楚了吗？确认我就出票了。

窗口前的购票者，在身后巨大的目光压力之下，在面前不耐烦的语言压力之下，做着迅速的购买决定。这种购票体验，真的是太烂了。唯一的好处是：当我们拿到了那张纸片，就放下心来，肯定能回家了。

假设，我们一开始就把12306做成一个售票大厅的模式，总共就100个窗口，每个人都登录以后先排上10个小时的队，一旦排上了，轮到自己了，购票时间不会超过2分钟。那么，虽然是漫长的10小时的等待，却不需要时刻守在电脑前站着。这种体验，我想就足够了。

从12306的角度而言，完全可以将系统按照每个城市一个售票大厅的方式来部署，一开始假设只有100个窗口，人再多也是这么排着。等到系统稳定了，能力上去了，再慢慢的增加窗口的数量，缩短排队的时间。痛骂的人，将会少很多很多。原因很简单，不要一开始就给用户一个很高的期待值，然后再让他们失望，而是基于现状，小步快跑的做着改进。反而会有较好的效果。

这种做法，其实在网游业是基本常识，随着用户数量的增加，新增一组一组的服务器，以容纳更多的玩家，而不是一开始就放开让所有的人进来玩。宁可不让他们进来，也不是让他们进来以后，在游戏场景里玩排队的游戏。

四、代售机制

火车票代售网点，其实在很多年前就已经出现了。我认为这个模式其实很不错，是一个分散客流提高效率的好办法。假设，我们不做12306的网站，而是开办成千上万，甚至上百万的火车票代售网店，情况会变成什么样子呢？假设，我们降低火车票代售点的准入门槛：交XX万押金，下载一个代售点客户端，自备电脑，自寻场地，自寻客源，自己去做生意。搞一个简单的审批流程，每年新增批准10万个个体户代售点。

这样的好处是：每个企业，每个公司，每个街道办事处，都可以自己申请成为一个代售网点，然后解决身边人购票的难题。在最大限度内，减少集中排队的压力。另一方面，由于审批流程可以控制代售点的数量，同时也就保证了系统的压力始终以可控的方式增长。

我在内心默默推理了一下，似乎是一个较为简单可行的办法。

五、架构演进

在网络上，我们常常能够看到很多给12306支招的方案，总之各种前卫，各种先进。但是，在我看来，越是复杂的系统，越是怕这种“革命”，哪怕过去的架构再不合理，也最好不要贸然引入过于激进的架构，在原有的架构下逐步演进，逐步扩展，逐步寻找小范围的、能够被改进的点来推进，才是较为合理的做法。

我能够看到的很多对于12306的批评，常常是一直站着说话不腰疼的姿态，说实话，并不可取。就目前来看，我们最乐观的估计是，12306能够顶住压力，逐渐改进、完善，在3~5年之后，渐渐淡出人们的视线，成为一个普通的，日常必须使用的，生活服务类网站。

六、抓大放小

说起用户体验糟糕，每个人都可以滔滔不绝的说很多话。我们常常会看到这样一种言论：铁道部的官员，他们用12306吗？如果他们也用，难道不会更加促使12306网站更快的改进吗？

其实，从技术人员的角度而言，怕的就是大老板亲自抓用户体验。当然，比这个更加糟糕的，则是每个领导，都对用户体验，说三道四。

对于12306的改进，我想不必过于关注细节，追踪一些统计数据的变化情况就好。比如：平均购票等待时间；退票率与废票率；列车上座率等等。至于如何提高这些数据，领导们千万不要事无巨细的参与讨论，大家各自努力就好。有更多的事情得靠领导们努力：比如切实提高运力...
其他

runfriends（来自论坛回复） 写道
第一：专业的事就应该找专家来做。不论招标也好，还是私下里寻找合作伙伴也好，都应该挑选有高并发、高吞吐量这方面的专家完成。而这样的人只存在于大型电商公司。铁道部花了那么多钱却没去找正确的人来做这件事。

第二：关键在于目的是什么。目的是花钱，还是为了方便买票，还是其它目的？

第三：关于抢票插件的问题。如果网站本身响应迅速，抢票插件也没什么市场了。关键在于要去考虑怎么改善用户体验，而不是要去禁抢票插件。上头意识从来都没有做正确的事。

酷壳博主说，就为了一年那么几次，十几天的高访问量，花那么多钱开发一个购票网站，也就铁道部能做的出来了。

个人觉的，更好的做法是。铁道部应该可以把购票api开放出来。让所有人都可以通过这些api开发购票网站。让这些网站之间形成竞争。

这样访问压力分散到了不同公司的服务器，而铁道部就是做了一个平台。这样做的效果更好。就像现在很多类似携程这样的网站都可以在上面订飞机票一样。

另外，通过云计算将根据一年中不同时段的压力弹性改变计算资源，也可以节省成本。


wangshu3000（来自论坛回复） 写道
问题瓶颈（Front to Backgroud）：

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

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