步步糕升 发表于 2026-10-8 07:41:26

12306:号称全球最复杂售票系统,春运亿级抢票为什么不容易崩

      每到春运抢票时段,数亿人同时蹲守放票时刻,无数请求瞬间涌向 12306 系统。很多人只是简单点一下购票按钮,感受就是 “付完钱票就出来了”,但背后系统要完成一整套极其复杂的运算与并发处理中国国家铁...。
      很多人会拿电商大促做对比,但火车票业务逻辑远比普通商品订单复杂。普通电商商品卖出去一件库存就减一件;火车票卖的不是座位本身,而是某一段运行区间内座位的使用权,同一个座位可以卖给不同区间的不同乘客。本文拆解 12306 核心技术逻辑,回顾系统从早期崩溃到如今稳定扛住春运大考的演进历程。

一、席位复用:一张座位,可以分段卖给多批乘客

以一趟北京开往上海、途经济南的高铁举例。如果一位旅客购买北京‑济南,下车之后,这个座位的济南到上海区间依旧是空闲的,系统可以把济南‑上海这段再卖给另一位乘客。
为了实现这套席位复用,12306 使用位图(Bitmap)来记录每一个座位各个停靠区间占用状态,可以把它理解成一把刻度尺,每一格代表一个站点区间:二进制标记 1 代表该区间已售出,0 代表空闲。用户提交购票请求,系统做快速位运算,校验目标行程对应的全部区间是否全部空闲;全部空闲才允许出票。这也就是大家经常遇到的现象:全程车票已经售罄,但中间短途区间仍然有余票。
这和电商库存逻辑完全不同:电商只需要记录剩余多少件;火车票需要对每一个座位、每一段区间做状态校验,业务复杂度成倍提升。
二、从 2012 年大面积白屏,到内存缓存扛住亿级查询

很多老网民还记得 2012 年春运,刚刚上线的 12306 系统遭遇严重卡顿白屏。当时绝大多数余票查询请求直接穿透到后端硬盘数据库,海量并发访问直接压垮数据库,大量用户页面打不开、提交订单失败。
后续架构改造最关键一步,就是把余票查询从硬盘数据库迁移到高速内存缓存(Redis 等内存数据库)。

[*]余票、车次热点数据优先存放在内存,内存读写速度远高于磁盘,绝大多数用户查余票请求直接在缓存层返回,不用访问底层数据库,极大减轻数据库压力。
[*]利用原子扣减、分布式锁机制处理抢票并发:同一座位同一时间只允许一个请求抢占成功,大量重复抢票请求直接在缓存层拦截,不会全部打入数据库,避免数据库被冲垮。
简单比喻:就像奶茶店,把高频查询信息摆在前台柜台(缓存),而不是每一次询问都跑去后台仓库(数据库)翻记录。
三、候补购票:把 “手速抢票” 变成排队机制

在候补功能上线之前,一旦有人退票,余票会直接放回票池,谁的手速快、脚本跑得快,谁就能抢到退票,普通用户非常吃亏。
候补系统本质是一套自动撮合队列:

[*]用户提交候补订单、预付票款,进入对应车次区间的排队队列,按提交时间排序;
[*]一旦出现退票、改签释放席位,或是列车加开产生新票源,系统自动扫描候补队列,优先匹配排位靠前的用户自动出票;
[*]全程不需要用户反复刷新 App,系统后台自动完成匹配兑现央视网。
候补机制改变游戏规则:比拼的不再是手速,而是提交候补的时间,也大幅减少第三方抢票脚本的优势。
四、多重手段削平春运瞬时流量洪峰

春运放票瞬间会产生爆发式流量,系统不能单纯依靠硬件硬扛峰值,采用一整套流量削峰策略:

[*]热门车次分批放票不会把全部车票同一秒一次性放出,拆分成多批次释放,把一瞬间的海量请求,摊开到数分钟时间,避免瞬间流量洪水冲击系统。
[*]弹性云扩容春运来临前,根据历史数据预估流量,云端动态扩容计算节点;高峰结束之后释放多余算力资源,不用常年维持超大闲置服务器集群,平衡性能与成本。
[*]验证码与人机风控很多用户不喜欢验证码,但它的核心目的不只是为难普通人,而是拦截批量脚本、抢票软件的机器请求,过滤大量无效访问,降低系统整体压力,间接提升真实用户抢票成功率。
[*]异步消息队列处理订单大量下单请求先进入消息队列排队,后端按照系统处理能力逐步消费,不会瞬间把全部压力压向数据库。
五、容易被混淆的两个概念:访问量 vs 实际出票

网上经常流传 “12306 每秒百万笔交易” 说法,这里要做澄清:

[*]春运高峰期,页面查询、点击访问的 QPS(每秒查询数)达到百万级别,是用户刷余票、刷新页面的请求;
[*]真实的出票订单每秒是千张级别;
[*]双十一的每秒 58 万笔,是成交下单订单,二者统计口径不一样,不能直接简单对比中国国家铁...。
12306 真正难的不是单纯的流量数字,而是高访问量叠加极其复杂的席位区间计算,还要保证全国席位状态强一致性,退票、改签实时联动,这在全球票务系统中都是巨大挑战。
六、全文总结

12306 并不是一个简单的 “卖票网站”。普通电商是卖固定数量商品,而火车票售卖的是座位分段区间使用权,依靠位图实现席位复用;依靠多级内存缓存拦截绝大多数查询压力;依靠分布式锁解决并发抢票;候补系统把手速竞争变成时间排队;再通过分批放票、弹性扩容、人机风控共同削平春运瞬时流量洪峰。
从 2012 年春运大面积白屏,到如今平稳承接数亿人的春运购票,背后是整套业务架构与工程体系的持续迭代升级。对普通旅客来说,善用候补功能,远比熬夜卡点刷新更有用。

页: [1]
查看完整版本: 12306:号称全球最复杂售票系统,春运亿级抢票为什么不容易崩