严肃科普：12306 能扛得住明星并发出轨级的流量吗？

12306: 这是我被黑得最惨的一次。

买着票了吗您？

又是一年春运到来时，每年的这个时候，大家见面的问候语就从“吃了吗您？”变成了“买着票了吗您？”，于是相视苦笑，“¥%#& 的 12306”。春运是这个星球上最大规模的人类迁移活动，每年有长达 40 天的时间里，空运、铁路、公路齐上阵，运送着数十亿人次的旅客。

铁路系统，更是其中重要一环，历年铁路春运数据一览：

• 2016 年，铁路春运 40 天累计发送旅客 3.03 亿人次；
• 2017 年，铁路春运 40 天累计发送旅客 3.57 亿人次；
• 2018 年，铁路春运 40 天累计发送旅客 3.8 亿人次；
• 2019 年，铁路春运预计发送旅客 4 亿人次。

12306 春运放票可谓是互联网史上最无辜的“饥饿营销”：放票一秒钟基本就没票了，挂个携程、同程、飞猪、智行刷上一星期也未必抢得着一张票，找黄牛、自己写抢票脚本，八仙过海各显神通，“洛阳亲友如相问，就说我在抢车票”。

于是乎，吃瓜群众们认为 12306 的系统简直太烂了，都提前一个月了还买不着票。就像全国有好几亿人想教张小龙做微信一样，大概也有无数人想教 12306 怎么出票。

于是乎有人问了，12306 的系统能扛住明星并发出轨级别的流量吗？

12306: 你不懂我，我不怪你

12306 的发展历程

• 2010 年 1 月 30 日（2010 年春运首日）12306 网站开通并试运行。用户可查询列车时刻、票价、余票、代售点、正晚点等信息。
• 2011 年 1 月 19 日（2011 年春运首日），中华人民共和国 18 个铁路局（公司）所在地也分别成立了铁路客户服务中心，并公布了服务热线。
• 2011 年 06 月 12 日，京津城际铁路率先试水网络售票。
• 2011 年 9 月 30 日，所有动车组线路实施网上订票。
• 2011 年 11 月 20 日，Z 字头全部直达特快列车车票实施网上订票。
• 2011 年 12 月 23 日，铁道部最终兑现在年底前网络售票覆盖所有车次的承诺。
• 2013 年 12 月 8 日，12306 手机客户端正式开放下载。
• 2015 年 1 月 16 日，阿里云方面证实，12306 网站 75% 的余票查询系统已经迁移至阿里云计算平台上。
• 2018 年 11 月 3 日，改版升级的中国铁路 12306 网站正式上线运营。

至此，12306 的布局、功能基本完善，在支撑春运的流量考验下持续着迭代之旅和来自没买到票群众的无情鞭挞。

12306 的设计模式

需求分析

服务旅客需求：

• 在线售票服务需求；
• 线下配套服务需求。

业务管理需求：

互联网售票涉及的票额、预售期、售票时 间、席别、票种、车次、车站、实名证件类型、网 站开放时间、业务办理时限、允许购票张数、售票收入统计、旅客投诉受理，异常用户处理等业务。

系统监控需求：

包括对互联网售票过程中涉及的软硬件设备进行资源利用、负载等运行状态的监控，以及对互 联网售票处理速度、购票旅客行为、订单状态等进 行监控，确保系统安全，稳定、高效运行。

系统结构、功能设计

铁路互联网售票相关的系统包括客票系统、12306 网站、互联网售票业务处理平台、铁路电子 支付平台以及站车无线交互平台 5 部分。如下图：

铁路互联网售票系统功能如下：

业务流程设计如下：

业务场景复杂在哪儿？

2012 年春运，由于访问量超出设计预期， 12306 网站在高峰期出现了页面打开缓慢、查询和下 单报错、后台系统过载等一系列问题。持续的高并发访问使系统在多个方面出现性能瓶颈，如下图：

在平时，12306 也就是个普通的购票网站。一旦到了春运、黄金周，12306 就是一个 1 全站所有商品都秒杀，所有 SKU 都是动态库存的存在。

从那以后，铁路系统的研发团队就一直在对系统架构、应用功能以及业务规则进行持续优化和改进。与此同时的，则是逐年刷新客流量峰值的春运、黄金周的高并发考验。

12306 的业务场景到底复杂在哪儿？

火车票跟很多票（包括各大电商的商品、机票、演唱会门票等）有不一样的属性。比如，从北京到广州，沿途有多个站点，理论上乘客可以选择任意 一段区间购票，所以每买一张区间票，可能同时裂变出多张区间票。这个逻辑比大多数电子商务系统要复杂的多。

购票差异还不仅限与此。比如再添加一些更人性化的功能：根据订票者身份证里的年龄优选上下铺、优选号等，那么查询和出票逻辑就更复杂了。

根据官方公布的数字，有人统计了一下：需要数千个 pv，才能出一张票。这个说法并不能得出“出票效率低”的结论，但是恰恰很形象地说明了查询量的巨大。

12306 的查询量不同于电商网站的商品查询，秒杀甚至饥饿营销抢购不到也就算了，火车票是抢不到也时刻惦记着甚至不惜写脚本 24 小时不间断刷新、查询的东西。

上图是爬虫流量的目标行业分布图，可以看到排第一名的是出行行业，而出行行业中近 90% 的爬虫流量都瞄准了 12306。

“12306 日均页面浏览量达到 556.7 亿次，最高峰时页面浏览量达 813.4 亿次，1 小时最高点击量 59.3 亿次，平均每秒 164.8 万次。”

这是加上验证码防护以后的数据，被拦在门外的爬虫流量有多少？不计其数。

上图是经过多次优化后的 12306 体系架构，可以看出比起前一张图，无论是系统的复杂程度还是结构的完善程度都有了巨大的提升。即便是这样，买不到票的人仍然很多。

事实上，像春运这样大规模的人类迁徙事件，从客观情况而言，技术只能起到缓解、改善、照顾到大部分人的作用。至于“根治”，需要的不仅是购票系统的技术水平持续提升，更加需要交通运输行业的持续进化。

回到最初的问题：12306 能扛得住明星并发出轨级的流量吗？

铁总：加机器扩容就能解决的事儿，不用来问我。

写在最后

普通人骂 12306，是因为他们不懂技术，也没有耐心去了解这背后的技术难点、业务场景复杂度。他们骂 12306，只是因为他们想回家。

要不我们再黑 12306 一把：如果让你来设计，你会给 12306 什么样的解决方案应对春运级别的流量？欢迎评论区留言告诉我们你的天才设想。