12306一票难求，双十一购物不亦乐乎，述说数据背后的玄机

双十一刚刚过去，人们不亦乐乎的各种欢乐购物，更有疯狂购物者，日夜坚守，在11.11到来的那一刻就守在电脑旁，准备进攻。有人因为没有秒杀到自己想要的商品痛心不已，不得其解，别人为什么能那么快抢购到商品。这和火车篇购物系统形成了强烈的反差。背后到底有什么差别呢？哪个环节存在差距，是数据处理导致系统瘫痪，繁杂的数据库难以应对还是什么原因？

12306火车票购票系统，逢假日必瘫痪，引发了强烈反响。铁道系统对于一票难求的答复是，购票人数太多，数据量过大。但是，在淘宝双11大促活动中，淘宝双十一总交易金额191亿，订单1亿零580万笔，其中无线支付近900万笔，支付宝核心数据库集群处理了41亿个事务，执行285亿次SQL，生成15TB日志，访问1931亿次内存数据块，13亿个物理读，核心MySQL集群一天支持了20亿个事务。12306火车票系统和其相比，真是天上地下。12306为何如此烂？

1. 淘宝技术被人称赞

在刚刚过去的淘宝双11大促活动中，淘宝的技术支撑受到了网民的追捧。据来自支付宝DBA@dbatools的透露：淘宝双十一总交易金额 191亿，订单1亿零580万笔，其中无线支付近900万笔，支付宝核心数据库集群处理了41亿个事务，执行285亿次SQL，生成15TB日志，访问 1931亿次内存数据块，13亿个物理读，核心MySQL集群一天支持了20亿个事务。

淘宝的技术人员以实际行动让网民折服，虽然在淘宝双十一活动刚开始的10分钟内的访问高峰期内，购物车和支付宝都出现了打不开的情况，但订单可 以生成，而且白天的系统运行比较正常。双十一期间，淘宝除了技术上的保障，还有大量的运维策略的支持，比如在峰值期间下订单优先级最高，支付可以晚点儿， 大额度的订单优先处理等等。

淘宝网采用什么技术架构来实现网站高负载的呢？据淘宝技术人员分享，淘宝的整体架构使用了如下措施来应对：一应用无状态(淘宝session框 架)；二有效使用缓存(Tair)；三应用拆分(HSF)；四数据库拆分(TDDL)；五异步通信(Notify)；六非结构化数据存储 (TFS,NOSQL)；七监控、预警系统；八配置统一管理。

2. 12306网站被人诟病

淘宝强大的技术实力，很容易让人们联想到让人“一票难求”的订票网站-12306。12306网站购票难的问题几乎成了所有人的共识。来自前支付宝架构师冯大辉（@Fenng）的这条微博翻出12306这笔账，别有一番滋味。

以冯大辉的计算方法，支付宝11月11日一天就处理了1亿零580万条交易请求量，而12306一天处理的交易（出票量）仅仅166万条，这还 主要是集中在8点钟开始放票之后的5分钟时间里。从结果来看，12306弱爆了，处理的交易量比支付宝“低了两个数量级”还那么弱不禁风。

冯大辉的微博马上得到了@caoz的转发响应，后者在9月底对12306的骂战中一战成名，由于观点相似，caoz和Fenng可以称为统一战线——当然，众多对12306充满怨恨的普通购票者也与他们在感情上统一战线。

简单分析一下12306的购票系统，为避免“黄牛”买票，购票系统有一个业务逻辑：一个有效身份证件同一乘车日期同一车次限购一张车票。因此购买一张车票可以简化为包含四个操作：

1) 判断同一乘车日期同一车次是否有未预订的空余座位

2) 判断这个有效身份证是否已购买过同一乘车日期同一车次的车票

3) 车票上标注的座位标记为已预订

4) 如果没有购买过，则该身份证预订一张车票

人们在12306网站上购买一张票的流程如下：

1）用户通过浏览器访问系统URL

2）界面集群F5将请求转发至某一节点，通过比较用户数据库的内容进行身份鉴权。

3）鉴权成功后进入订票，提交订票订单（查询流程暂不讨论）界面显示请等待

4）订票消息被发送至总线部件（接口可用webService、RMI、甚至自定义协议都可以）

5）总线收到订票消息、去Cache集群查询相关车次

6）Cache根据自身维护的车次余票表，返回查询结果，如果有余票，转7）。如果无票了，则总线返回界面集群“没票了”，界面提示用户明天再试。

7）若有余票，则总线返回界面集群“正在出票，请等待”，并将订票请求压入队列。且发消息至Cache，告诉CACHE将订票请求加入队列。

8）Cache收到总线队列增加1个的消息，将自身维护的对应车次余票数减1个。

9）总线另一线程负责从队列中取消息，并发送至出票部件。

10）出票部件产生订票结果，并修改数据库，发送“订票成功”消息回总线。

11）总线将订票成功消息直接回传至界面集群。

12）用户看到订票结果。

3. 跟淘宝相比，12306网站的有独特的技术难度

1) 火车票属于竞争性资源。淘宝的交易是相对离散的，分散在成千上万的卖家当中，同时对同一商家同一商品的并发购买并不是特别高。因此在数据访问上不会有太大 的锁同一数据的瓶颈，买火车票在这方面压力会更大，最主要的原因还是僧多粥少的。火车票是几千人，几万人抢一张票，火车票的抢购场景也只有在淘宝秒杀的时 候可以类比，但是网民参与的秒杀也很难成功秒杀到商品。

2) 火车票资源稀缺，需要同线下数以万计的购票点、电话订票等进行互斥。每张火车票都是独一无二的，网络售票只是数以万计的购票终端的一个终端而已，需要跟其 他售票系统保持数据一致性。淘宝的商品只需要查询库存量就可以了。举个粗略的例子，火车票的供需关系可能是1：10，淘宝货品与消费者的供需关系可能是 10：1，技术革新解决不了某种商品严重供不应求的本质问题。淘宝上的商品天然没有全局一致性的问题，做技术上做分区优化就简单得多了。火车票买卖的每笔 业务都要互斥，以检查有没有票，一个人是否买了多张票等等。从这个角度可以理解为卖票问题的技术难度大得多，属于世界级难题。

3) 火车票的信息是实时更新的。网民的每次操作都必须到后台查询，实时生成新的火车票的状态信息。淘宝商品库存信息在促销期间不准确，这是服务端为了关键性能 做妥协；但订火车票，库存信息必须是实时的。铁道部2012年春运每天安排大约2000对列车，座位大概400万个，因为每个座位都可能有不同的购票方式 （火车票代售点、电话订票等），所以都需要计算，提前10天预售，应该有点类似于taobao同时提供400万件商品的秒杀活动。

4) 票务业务的复杂性非商品信息可比。选票最大的问题不是直达，是换车！只要有换车，计算量级都是“次方”往上增加。比如上海-西安，中间在郑州换。但系统计 算的时候会出现“上海-北京-西安”的路线，这条线路是没有选的，但会消耗计算资源，2000条线路+临时车+换乘，还有就是瞬间的并发，这个也是一个问 题。

5) 12306网站后面的票务系统问题。12306网站不是一个孤立的系统，虽然这网站也很多地方可以优化，但估计最大的瓶颈是后面那个和全国的代售点火车站 共用的票务系统。真正的火车票数据库是在铁路系统中独立存在的，这个铁路系统反应慢才是制约12306网站慢的主因。所以最大问题可能不是负载并发问题， 而是老票务系统的问题。票务系统采用的是突然放票，而有的票又远远不够大家分，所以，大家才会有抢票这种有中国特色的业务的做法。于是当票放出来的时候， 就会有几百万人甚至上千万人杀上去，查询，下单。几十分钟内，一个网站能接受几千万的访问量，这个是很恐怖的事情。据说12306的高峰访问是10亿 PV，集中在早8点到10点，每秒PV在高峰时上千万。这需要逐步全面革新。

6) 独特的车票预留问题。传统票务系统有一个比较复杂的地方就是各种预留票规则，每个城市，每个节日都有很多的复杂留票规则，导致很多时候头十天一张卧铺都没有，但是等到最后就有很多票，这些使本已稀缺的资源更加紧张。

4. 结论：淘宝的网站优化技术大多不适用于12306网站

淘宝的网站优化技术中采用了大量的缓存技术和分布式策略，火车票的状态是实时计算，实时更新的，缓存只能解决网站前端的一小部分问题，但解决不了人们抢票和出票慢的根本问题。