抢不到回家的票，还真不是12306技术不行

临近春节，12306崩溃一次，就有人心碎一次。

12月23日上午，有不少网友爆料称12306出现了车次加载失败、购买不了票或卡在候补订单支付界面的情况，疑似因抢票人数过多，导致服务器崩溃。12306客服后来回应，原因可能是操作旅客过多，系统繁忙造成的，可尝试重新卸载安装客户端或切换网络。至于春运期间是否将加强技术保障，客服称需要反馈给相关技术部门才能得知。

似乎每年在春运的节骨眼上，12306总要掉几回链子。已经有人学会了苦中作乐，有网友想到兴许能报个旅行社回家：

有人出主意不然就直接买辆车吧，路上还能拉个顺风车赚钱：

很多人虽然总喊着过年太烦太累，但家毕竟还是要回。按照2020年春运火车票网络订票提前30天发售的规定，12月23日已经可以购买2020年1月21日的车票，正是抢票高峰期。在离春节假期只剩整一个月的当口，绝大多数归心似箭的人还是被这波宕机搞得非常着急。

12306每次宕机都伴随着一片骂声，这次也不例外。大家不明白为什么这么久过去了，12306还是如此让人糟心。这个问题并不简单，它涉及到我国复杂的国情和背后的种种技术，不是一句话就能说清，我们亦无法轻易给12306定性。

但有一点可以肯定，作为世界上公认规模最大、特定时段最繁忙的实时交易系统之一，能在绝大部分时间保证平稳运行，12306已经相当不容易了。

为什么会抢不到票？

在解释这次12306为什么会崩溃前，我们有必要先了解一些它的基本规则。

一直以来，中国铁路都存在一种被叫做“区间限售”的售票模式。它某种程度是对硬纸板票售票模式的延续，在硬纸板票时代，每辆车在每个车站、每个区间发售的车票都需要提前印刷好，因此售票部门会事先给每趟车不同区间的车票数量制定指标。

在互联网时代，这种指标分配仍然存在，于是渐渐有了区间限售的说法。 这种售票模式遵循的原则，12306官方的 对外解释 是“弃短护长” 。

举个简单的例子（仅作举例不代表真实情况），针对从北京始发经由济南、南京，最终到达上海的G1次高速列车，在一开始售票的时侯，大概率不会发售从济南到南京段的车票，或者会在开始时限制这一区间销售的车票数量（不放出全部车票），为的是保证北京到南京、上海的长途旅客的出行需求。

因为一旦你先买了济南到南京的车票，意味着你不仅占用了从北京到南京的一个席位，还占用了一个从北京到上海的。不论是就方便长途旅客（没人愿意从北京到上海三段区间换三次座位），还是减轻铁路系统的工作负担，区间限售都是目前最合适的解决方案。

这也在一定程度上解释了火车票为什么难抢，一边是巨大的人口基数，一边是区间限售的措施，都让车票在刚一放票就被秒光。虽然在临近开车的一段时间内，为了调控需求、提高列车利用率，会解除限售放出一些没有卖出的余票，但在春运这样交通资源极其紧张的时候，人们一天买不着票就要多操心一天，伤时伤财伤感情。

越是需要拼手速，第三方抢票软件就越有利可图。越来越多人选择放弃使用12306官网及App手动订票，转而把抢票任务托付给携程、智行等等的第三方软件和机器。

人工刷新永远快不过机器，第三方抢票软件给12306带来的是巨大且更频繁的数据量。一名曾在第三方软件的火车票部门工作过的知乎匿名用户如此回忆，“就我们每天往她（12306）塞的流量，基本上小电商网站都要崩溃，而且我们更早地提出过站补票，买短程票延长，提供机票加火车加汽车一系列的解决方案，查询量非常大。”

12306为什么会崩溃？

第三方抢票软件给12306带来的压力，基本都在余票查询环节，这也是12306的崩溃之处。

查询环节就涉及到12306库存机制的复杂性。事实上早在2014年，一位ID名为“代码狗”的前淘宝工程师就在著名论坛“西西河”上 发文 表达过他对12306的看法。他曾认为12306的系统很容易搭建，于是发起了一个名为“替12306设计系统”的开源项目，然而工作中的实践彻底改变了他对12306的认识。

12306系统的复杂之处就在于，它的SKU（即Stock keeping Unit，库存保有单位）并不像一般电商那样，可以通过区别货品有和没有来简单计算，而是需要结合每条线路的不同区间来做复杂运算，并且，12306的SKU还是时刻动态变化着的。

这里引用“代码狗”举的一个从北京西到深圳北的G71次高速列车的例子（仅讨论理论世界的模型）。这趟列车共有17个站，3种座位，表面上看这是3种商品（商务座、一等座和二等座），但实际上，G71的商品种类多达408种（注意：这里指的是商品种类，而非具体的商品数量）。

计算方法是，如果卖北京西始发的车票，共有16种卖法，因为后面有16个站，分别是北京西到保定、石家庄、郑州、武汉、长沙、广州、虎门……每个区间都可以看作是一种独立的商品。同理，如果是从石家庄站始发，共有15种卖法，以此类推。所以单按车站区间来计算，G71的商品种类为：16+15+14+…+2+1=136种。再考虑进3种座位类型，商品种类就成了：136*3=408种。

我们再来看G71是怎么减库存的。假如旅客A买了一张区间为北京西到保定东（即顺序数北京西的下一站）的车票，那么G71的SKU就要减去16个，包括北京西到余下16个车站每个区间都要减1（注意：这里指的就是商品数量了，可以暂时不需考虑座位类型）。

同样，假如旅客B买了一张区间为北京西到深圳北（即终点站）的车票，G71的SKU就要减去136个，包括北京西到余下16个车站每个区间减1，保定东到余下15个车站每个区间减1，石家庄到余下14个车站每个区间减1……所以减去的库存为：16+15+14+…+2+1=136个。

G71的商品种类本来已经够多了，库存减起来更是繁琐。可见，12306的动态库存比我们平时买东西的任何网站的库存机制要复杂太多太多， 等于旅客每买一张车票，12306就需要更新相应线路的所有车票数据 。

有业内人士称，余票查询系统访问量巨大，占12306整个网站流量的90%以上，业务高峰期并发请求密集，性能要求是整个业务系统中最为重要的一环。

当第三方抢票软件加上人工查询涌入的数据量超出12306的计算能力时，崩溃就发生了。

不是12306不努力

对于12306来说，应对的方法无非两种，一种是打击第三方抢票软件，一种是升级服务器。实际上，这些12306也早就想到了。

为了打击抢票软件，12306尝试过的办法就包括了最早的字母数字组合验证码，后来槽点颇多的图形验证码，规定半年内不得删除常用联系人，每个注册的账户必须经过实名验证，以及推出“官方的抢票功能”候补购票等。

当年12306的图形验证码被玩坏了

经过如何、道理怎样不再赘述，但结果是，种种复杂的限制最后总能被第三方软件想方设法破解，这不现在一些抢票软件已经能帮你实现“官方候补”（别问我怎么知道的），而12306的候补功能今年5月才刚正式上线。

服务器方面，12306针对余票查询系统有过的两次较大升级。

一次是在上线后的一年内选择与美国科技公司Pivotal（中译“毕威拓”） 合作 ，引入后者的GemFire分布式内存计算平台技术率先对12306的余票查询系统进行改造。“分布式数据处理”和“集中式数据处理”概念相对，在解决12306的票务问题上分布式计算更有优势（不懂两者区别的朋友请自行搜索）。这次技术改造效果明显，让12306暂时舒了一口气。

12306引入Pivotal GemFire改造后的成效

另一次则是和阿里云的合作。据一名自称是阿里云程序员、参与了2015年12306春运项目工作的 知乎匿名用户称 ，在2014年初双方团队就已开始讨论如何将余票查询系统放到云上，并在2015年春运期间将12306 75%的余票查询业务放到云上。

云计算相较于GemFire这样基于内存的分布式集群系统功能更进一步，在提升余票查询能力方面，云计算可以快速部署应用提供服务，通过分钟级的扩容操作，实现十倍、百倍的服务能力扩展。

了解了这些，我们恐怕真的不能指责12306不努力。尤其是考虑到每年只增不减、屡创新高的春运铁路出行人次，12306几乎年年都要面临大考。

把近五年的铁路春运数据放在一起比就很明显了，2015-2019年春运铁路总计发送旅客人次分别是：2.95亿、3.26亿、3.57亿、3.8亿和4.1亿。据12月25日国家发展改革委、交通运输部、公安部、国铁集团等八部门联合召开的 电视电话会议预测 ，2020年全国春运铁路发送旅客将高达4.4亿人次。

你可能会问，既然如此，12306为什么不多买一点服务器呢？ 有人 举了这样一个例子，

“十一黄金周的时候，北京主城区到八达岭长城的路堵得严严实实，但不能因为黄金周出行高峰，就把这段路修成长安街那样10车道的公路。花大价钱修了一段路，黄金周是可以飙到80公里/小时了，可平时呢，拿来给两边的居民晒谷子？逼着12306买一大堆服务器对付春运，和逼北京修一条10车道的高速公路去八达岭长城一个道理。”

再者，即便是买了更多服务器，当前中国的铁路运力摆在那，依然会有人抢不到票。

所以别总抱着“12306技术不行”的怨念不放了，那样没有意义。就像一位12306工程师回顾系统刚上线时说的，“其实我们知道，他们骂的不是12306，他们骂的是这个时代。”