作为全球最大最繁忙的特定时间实时交易系统之一，它可以保证大部分时间的顺畅运行时间到了，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（StockkeepingUnit）不像普通电商，可以简单的通过区分商品是否有货来计算，而是需要结合各个不同的版块线的用于执行复杂的计算，而12306的SKU仍然一直在动态变化。 这里以“代码狗”引用的北京西到深圳北的G71高铁为例（只讨论理论界的模型）。这列火车有17个车站和3种类型的座位。G71表面上是3种商品（商务舱、头等舱、二等舱），但实际上G71的商品种类多达408种（注意：这里指的是商品种类，不是商品种类）具体数量的产品）。 计算方法是如果卖北京西出发的车票，有16种卖法，因为后面有16个站，分别是北京西到保定、石家庄、郑州、武汉、长沙、广州、虎门……每一个区间都可以看作是一个独立的商品。同样，如果是从石家庄站出发，则有15种销售方式，以此类推。因此，仅以站段计算，G71的商品种类为：16+15+14+...+2+1=136种。考虑3种座位，产品类别变为：136*3=408种。 让我们看看G71是如何减少库存的。如果旅客A购买的是北京西至保定东一段（即北京西下一站）的车票，则G71SKU减去16个SKU，包括北京西各段至剩余16个站点的所有必须减1（注：这里指的是商品数量，座位类型暂时可以不考虑）。 同理，如果旅客B购买的是北京西到深圳北（终点站）区间的车票，G71SKU减去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引入PivotalGemFire后的改造成果 又一次与阿里云的合作。据自称阿里云程序员、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，而是这个时代。”
