国庆假期，你在12306上抢到票了吗？
虽然每到节假日“高铁票好难买啊”“为什么开票就抢了还是候补呀”等吐槽不绝于耳，但从2011年6月12日上线起，中国铁路客户服务中心12306平台至今已不知不觉走过了13载春秋，也成为了大部分旅客乘坐高铁出行的首选购票平台。
回顾12306的发展历程可以说是一部与抢票软件斗智斗勇，“魔高一尺道高一丈”的“史诗”。
2024国庆，铁路迎来客运高峰ICPhoto
一切还得从12306成立的时候说起。随着2011年6月12日第一张京津城际铁路电子客票的售出，中国正式拉开了铁路网络售票的序幕，此后短短几个月，网络售票的范围就急速扩展到了京沪、武广、郑西等高铁线路。到9月30日，全国范围的高铁车票（G字头、D字头）都可以上12306购买。到2011年底，全国范围的火车车票（Z字头、T字头、K字头）都可以上12306购买。仅用了半年时间，中国铁路网络购票就完成了“从无到有”到“全面普及”的飞跃！
但铁路网络购票的新鲜感还没消散，2012年的春运便悄然而至，春运——这一世界罕见的人口大迁徙盛况，每年都会给中国的交通行业带来前所未有的压力，可以说是交通行业的“大考”。而12306的第一次系统崩溃也来得出乎所有人的预料。
从2012年1月5日起，12306网站连续5天点击量超过10亿次，访问量环比上月激增10余倍，其中1月9日点击量超过14亿次，成为全球最繁忙的网站之一——要知道2011年底中国网民也才5亿人。
对于这样的访问压力平台在建设之初并非没有考虑到。12306系统建设之初，在借鉴和参考客票核心系统架构的基础上，根据互联网应用的特点，研发者们为系统设计了缓存服务、用户管理、车票查询、订单及电子客票处理等多个相对独立的业务分区，以及三级网络安全域，分别是外网、内网和客票网。上线前的压力测试，一笔流程包含用户登录、车票查询、下单及支付等业务操作，系统极限交易能力为34张/秒，按高峰期10小时计算，售票量可达到120万张/天的设计能力。
然而，压力测试却漏算了一个“不速之客”——抢票软件。抢票软件是一种基于浏览器的插件，利用机器的快速反应来帮助用户完成不断查询和刷新页面的动作，通过高频查询车次余票、自动填写个人信息、多账号同时操作等方式，从而比手动购票的用户更快完成购票流程。
苦于平台“无票”的旅客为了确保万无一失只能花钱求助抢票软件
由于缺乏对抢票软件造成的超大流量访问的充分预估，导致12306在大量抢票软件面前不堪一击——12306网站出现瘫痪情况，大量用户无法登录，页画刷新时间长达30分钟，订票付了款却无法购票。不少购票者无奈地怒斥12306网站“形同虚设”。
但是开弓没有回头箭，12306客票团队只能背水一战了：针对带宽不足的问题，12306客票团队当机立断，迅速将带宽由600兆上调至1000兆，不久又上调至1500兆；客票团队对网上购票数据进行监控与分析后发现，极个别用户在网上大量购票，单日购票总量竟超过100张。为保证购票公平，自1月5日起，12306客票团队对网上购票流程进行了调整，在用户购票成功后系统将强制用户退出，再次购票时需重新登录。
原铁道部还想到了邀请“外援”，当时所有网站中有丰富的“短时间内访问量剧增下不垮掉”经验的莫过于“双十一”搞得如火如荼的天猫和淘宝了。于是，阿里巴巴集团派出17名技术精英组成项目组，协助12306网站进行优化和改进。两支团队并肩作战，使12306网站的用户体验得到了极大地改善。系统的每日售票量由1月上旬的65万张提高到100万张以上，并于1月20日创造了119.2万张的日售票最高纪录。
天猫淘宝商城的“双11全球购物狂欢节”宣传广告霸屏上海徐家汇地铁站争夺用户人气流量IC Photo
这场上线不到一年的春运“极限测试”过后，互联网上也出现了关于12306架构的讨论和争议，当时的铁道部通过认真听取各方意见，也在认真梳理问题的原因，总结出主要是由于车票查询以及订单/电子客票业务分区处理能力不足，造成高峰期高并发访问请求下响应时间过长，加之各个业务分区未能很好进行隔离，导致系统由内至外产生“雪崩”效应，造成网站拥堵，影响用户的购票体验。
针对上述问题及原因，研发者将架构优化及重构思路重点放在提升车票查询和交易处理的响应速度，提升后台系统的扩展性，改变网上排队方式，减轻高峰时段集中放票造成的带宽压力。同时尽可能分离核心业务，减少业务环节间的强关联，具体内容包括：
首先，必须大幅提升并发查询能力，12306使用内存计算数据库取代传统数据库，将车票查询的响应速度由不足1000次/秒提升至超过20000次/秒，响应时间由原来的1s缩减至10ms，使用户可以快速获取到车次及余票情况。
其次，要让用户在高峰期“排队下单不拥堵”，为此12306构建了交易处理排队系统，队列的下单请求接收能力超过10万笔/秒，用户可以在售票高峰期迅速完成下单操作，等候系统依次处理，等候过程中可以查询排队状态（等候处理的时间）。排队系统中也采用了内存计算数据库。
第三，对订单/电子客票进行分节点分库分表改造，将原有的1个节点、1个库、1张表拆分为3个节点、30个库、30张表，线上相关操作被分散到各个节点和库表中，这样，用户在网站上的订票请求可以得到更快的响应和处理。
最后，对订票、取票操作进行了业务分离，由不同的业务节点（售票节点和取票节点）承载网上售票和线下取票业务；对订单/电子客票生成和查询进行了读写分离，使用内存计算数据库集中存储订单/电子客票，订单查询的响应速度由200次/秒左右提升至5000次/秒以上，大幅提升了订单/电子客票的查询效率。
优化架构后的系统在上线前压力的测试中，极限交易能力为300张/秒，可以满足日售票量500万的业务需求。2013年春运，优化架构后的12306网站最高日售票量达到364万，占全路售票量的40%，售票量为2012年春运最高峰（119万）的3倍多。
2013年2月14日，家长带着孩子在安徽省淮北火车站候车返程。IC Photo
然而，对于12306平台的需求依然在急速增长，原有的改良很快到达极限。2013年十一黄金周，12306互联网售票量达到了460万，再次接近系统处理的上限，且由于3G网络的限制（4G网元年但未普及）和网民数量的迅速增长导致高峰期外网入口带宽紧张，已不能满足互联网售票量进一步提升的需要。此外，作为铁路售票的主要渠道，互联网售票系统单中心运行模式已不能满足业务安全性和可靠性的需求。
为此，自2013年底起启动了12306网站的第2轮架构优化：
将用户登录及常用联系人查询等业务迁移至内存数据库中，提高了相关业务的处理性能和可靠性。
构建了铁科院第2生产中心，与既有的中国国家铁路集团有限公司第1生产中心间实现“双活”，提升网站的安全性和可靠性，并将订单/电子客票集群的处理能力提高1倍。订单/电子客票集群扩充至10组节点、100个库、100张表。
在公有云上部署车票查询服务，通过策略配置可随时将车票查询流量分流至公用云，以缓解在售票高峰期网站的处理资源和带宽压力。
上线前的压力测试验证了系统可以满足1000万张/天的设计售票能力，在2015年春运高峰时段，实际售票速度超过了1000张/秒（约合360万张/时）。公有云在2015年春运期间最高分流了75%的查询请求，网站对外车票查询服务能力增加了3倍。12306网站在2015年春运高峰日处理了超过180亿次车票查询服务，平均响应速度超过30万次/秒。
随着12306对于春运“极限压力”的承载能力超级加倍，一度让设计和运营团队头疼不已的“抢票外挂”已然成为了最大的不稳定因素。12306团队虽然一再抗议购票使用抢票软件，但是网络上依靠自动频繁刷新车票信息、进行自动填报抢票的小软件依旧层出不穷。这类软件通过快速刷新票务信息，提高抢票成功率，旨在帮助用户在第一时间抢到车票。虽然满足了市场需求，但同时严重干扰了手动购票的大众，影响了购票的公平性；且为了提高成功率，用户往往需要提前在系统输入乘车人的个人信息，在“抢票”的焦虑中，亲手将个人信息泄露了出去。
在这样的背景下12306团队也必须做出有针对性的改变——除了持续优化系统的高峰处理能力外，还引入了实名制、复杂验证码、手机验证码等功能，但依旧无法遏制抢票软件的猖獗，导致在春运、十一黄金周期间依旧出现网络不畅的购票现象。
直到2019年春运期间，12306试点候补购票服务功能。这一功能是将手动操作的用户订单与抢票软件的用户订单放到同一个“奖池”里，大家进行公平竞争，系统随机挑选“中奖者”完成接下去的购票流程，这样一来，即使刷屏再快的抢票软件也再无优势可言，这才使得抢票软件的风头被逐渐遏制。
正所谓“魔高一尺道高一丈”，候补票模式是12306针对抢票软件的一记重拳，但在利益的驱动下，抢票软件必定会继续针对这一模式再次进行不公平的竞争，例如提高抢票软件订单在候补票奖池中的“中奖概率”等。相信我们12306团队能够克服困难，维护好全球访问量最大、交易量最大的票务系统，双方的“斗智斗勇”依然伴随着中国不断发展的铁路网络和居民出行的需求不断进化着。
相关文章
头条焦点
精彩导读
关注我们
【查看完整讨论话题】 | 【用户登录】 | 【用户注册】