一览与观察者网︱从抢票大战到智慧购票：12306如何打破购票瓶颈

从抢票大战到智慧购票12306如何打破

购票瓶颈

✦

12306的发展历程可以说是部与抢票软件斗智斗勇的恢宏史诗，12306与抢票软件的关系概括成一句话便是“道高一尺，魔高一丈”。

✦

但是由于缺乏对抢票软件的充分预估，导致12306在大量抢票软件面前不堪一击。抢票软件是一种基于浏览器的插件，利用机器的快速反应来帮助用户完成不断查询和刷新页面的动作，通过高频查询车次余票、自动填写个人信息、多账号同时操作等方式，从而比手动购票的用户更快完成购票流程。

但是开弓没有回头箭，12306客票团队只能背水一战，迎难而上了：针对带宽不足的问题，12306客票团队当机立断，迅速将带宽由600兆上调至1000兆，不久又上调至1500兆；客票团队对网上购票数据进行监控与分析后发现，极个别用户在网上大量购票，单日购票总量竟超过100张。为保证购票公平，自1月5日起，12306客票团队对网上购票流程进行了调整，在用户购票成功后系统将强制用户退出，再次购票时需重新登录。

在这场攻坚战中，原铁道部希望借鉴淘宝、天猫网站“双十一”重压之下跨不掉的经验而提出邀请，阿里巴巴集团派出17名技术精英组成项目组，指导和协助12306网站进行优化和改进。两支团队并肩作战，使12306网站的用户体验得到了极大的改善。系统的每日售票量由1月上旬的65万张提高到100万张以上，并于1月20日创造了119.2万张的日售票最高纪录。

春运过后，互联网上也出现了关于12306架构的讨论和建议热潮，通过认真听取各方意见，梳理上述主要问题的原因和关联关系，结合系统监控数据，总结出主要是由于车票查询以及订单/电子客票业务分区处理能力不足，造成高峰期高并发访问请求下响应时间过长，加之各个业务分区未能很好进行隔离，导致系统由内至外产生“雪崩”效应，造成网站拥堵，影响用户的购票体验。

针对上述问题及原因，研发者将架构优化及重构思路重点放在提升车票查询和交易处理的响应速度，以降低查询和交易的延迟。同时尽可能分离核心业务，减少业务环节间的强关联，具体内容包括：

1. 使用内存计算数据库取代传统数据库，大幅提升车票并发查询能力，车票查询的响应速度由不足1000次/秒提升至超过20000次/秒，响应时间由原来的1s缩减至10ms，使用户可以快速获取到车次及余票情况。

2. 构建交易处理排队系统，系统先通过队列接收用户的下单请求，再根据后端处理能力异步地处理队列中的下单请求。队列的下单请求接收能力超过10万笔/秒，用户可以在售票高峰期迅速完成下单操作，等候系统依次处理，等候过程中可以查询排队状态（等候处理的时间）。排队系统中也采用了内存计算数据库。

3. 对订单/电子客票进行分节点分库分表改造，将原有的1个节点、1个库、1张表拆分为3个节点、30个库、30张表，线上相关操作被分散到各个节点和库表中，有效提升了核心交易的处理能力并具备继续横向扩充能力，使用户在队列中的订票请求可以得到更快的响应和处理。

4. 对订票、取票操作进行了业务分离，由不同的业务节点（售票节点和取票节点）承载网上售票和线下取票业务；对订单/电子客票生成和查询进行了读写分离，使用内存计算数据库集中存储订单/电子客票，订单查询的响应速度由200次/秒左右提升至5000次/秒以上，大幅提升了订单/电子客票的查询效率。

优化架构后的系统在上线前压力的测试中，极限交易能力为300张/秒，可以满足日售票量500万的业务需求。

此外，面对淘宝、天猫、京东商城等网站重压之下垮不掉的技术，2012年 “双十一”期间，12306客票团队组团到阿里巴巴集团取经，向其技术人员、运营维护团队学习经验，弥补自己的不足。这一年，12306客票团队主要做了3件事：提升后台系统的扩展性，使得系统在突发情况下便于优化；引入内存计算技术，缩短查询时间，提高查询效率；改变网上排队方式，把原来4个时间节点放票改为10个节点放票，其间每小时均有部分新票起售，减轻高峰时段集中放票造成的带宽压力。

2013年春运，优化架构后的12306网站最高日售票量达到364万，占全路售票量的40%，售票量为2012年春运最高峰（119万）的3倍多，各铁路局客票系统以及12306网站性能稳定，运行平稳，充分证明了架构调整的有效性。2013年十一黄金周，12306互联网售票量达到了460万，再次接近系统处理的上限，且由于3G网络的限制（4G网元年但未普及）和网民数量的迅速增长导致高峰期外网入口带宽紧张，已不能满足互联网售票量进一步提升的需要。此外，作为铁路售票的主要渠道，互联网售票系统单中心运行模式已不能满足业务安全性和可靠性的需求。为此，自2013年底起启动了12306网站的第2轮架构优化，优化目标旨在提高系统的安全可靠性，以及在高峰期具备处理容量的弹性扩充能力，具体内容包括：

1. 将用户登录及常用联系人查询等业务迁移至内存数据库中，提高了相关业务的处理性能和可靠性。

2. 构建铁科院第2生产中心，与既有的中国国家铁路集团有限公司第1生产中心间实现双活，提升网站的安全性和可靠性，并将订单/电子客票集群的处理能力提高1倍。

3. 在公有云上部署车票查询服务，通过策略配置可随时将车票查询流量分流至公用云，以缓解在售票高峰期网站的处理资源和带宽压力。

在双活架构的建设过程中，研发者将订单/电子客票集群完全迁移至X86虚拟化平台，并扩充至10组节点、100个库、100张表。上线前的压力测试验证了系统可以满足1000万张/天的设计售票能力，在2015年春运高峰时段，实际售票速度超过了1000张/秒（约合360万张/时）。第1生产中心、第2生产中心间订单/电子客票集群具备热切换能力，显著提高了系统的故障隔离能力和系统的安全及可靠性。

公有云在2015年春运期间最高分流了75%的查询请求，网站对外车票查询服务能力增加了3倍。基于CDN缓存服务（一级缓存）、双中心及公有云缓存服务（二级缓存）、双中心及公用云车票查询集群（实时计算），12306网站在2015年春运高峰日处理了超过180亿次车票查询服务，平均响应速度超过30万次/秒。

此后，12306团队虽然一再抗议购票使用抢票软件，但是网络上依靠自动频繁刷新车票信息、进行自动填报抢票的小软件依旧层出不穷。这类软件旨在帮助用户在第一时间抢到车票，缓解用户购票压力。这些软件通过快速刷新票务信息，提高抢票成功率，满足了市场需求。但同时严重干扰了手动购票的大众，影响了购票的公平性；且为了提高成功率，用户往往需要提前在系统输入乘车人的个人信息，亲手将个人信息泄露了出去。

✦

12306团队除了持续优化系统的高峰处理能力外，还引入了实名制、复杂验证码、手机验证码等功能，但依旧无法遏制抢票软件的猖獗，导致在春运、十一黄金周期间依旧出现网络不畅的购票现象。

直到2019年春运期间，12306试点候补购票服务功能。这一功能是将手动操作的用户订单与抢票软件的用户订单放到同一个“奖池”里，大家进行公平竞争，系统随机挑选“中奖者”完成接下去的购票流程，这样一来，即使刷屏再快的抢票软件也再无优势可言，这才使得抢票软件的风头被逐渐遏制。

正所谓“道高一尺，魔高一丈”，候补票模式是12306针对抢票软件的一记重拳，但在利益的驱动下，抢票软件必定会继续针对这一模式再次进行不公平的竞争，例如提高抢票软件订单在候补票奖池中的“中奖概率”等。相信我们12306团队能够客服困难，维护好全球访问量最大、交易量最大的票务系统！

2024年，与我们来一场步履不停的旅程

In 2024, join our endless journey

En 2024, participez à notre voyage sans fin

2024年、私たちと絶え間ない旅に出かけよう

En 2024, únete a nuestro viaje interminable.

في عام 2024، انضم إلى رحلتنا اللانهائية.

2024, ร่วมเดินทางกับเราในการผจญภัยที่ไม่มีที่สิ้นสุด

2024, எங்களுடைய நிரந்தர பயணத்தில் சேருங்கள்.