前言

🍊缘由

你春运抢不到的票，12306 是怎么扛住的？

凌晨开票，你盯着 12306 倒计时，5、4、3、2、1——点下去，灰了。
你骂一句"又没抢到"，然后去候补排队。可你有没有想过：同一秒，全国有几百万人在点同一个按钮？
12306 怎么没崩？它怎么知道还剩几张票？怎么保证不超卖？

🏀事情起因：
大家好，我是 JavaDog程序狗。今天聊一个国民级产品——12306。

每年春运，这套系统要扛住全球最大规模的人口迁徙购票需求。2025 年春运，12306 最高日页面访问量超 2600 亿次，单日售票峰值 2162 万张，每秒超过 1000 张票被售出。

这和双十一是两码事。双十一是攒了一天的大促，春运的流量要持续 40 天。热门线路开售那一瞬间，访问量能比平时暴涨几十倍，像个实实在在的流量洪峰砸下来。

但 2012 年春运，12306 上线还不到一年，直接崩了。连续 5 天日点击量超 10 亿次，系统频繁卡死、瘫痪，网上骂声一片。

从崩溃到扛住 2600 亿次，12306 用了十几年。这十几年里踩过的坑、填过的坑，对咱们做架构的都挺有借鉴意义。

今天我把 12306 的架构演进拆成四层，从"单体扛不住"聊到"混合云双活"。不用背，看完你就知道自己的系统卡在第几层。

🎯主要目标

本文带你走完一条架构演进路线

• 初学者：单体直连数据库，2012 年春运"雪崩"
• 进阶：异步排队 + 内存余票计算，从秒级到毫秒级
• 高级：分库分表 + 读写分离 + 售取分离，TPS 翻 25 倍
• 架构师：混合云 + 双中心双活 + 风控，扛 2600 亿/日

正文

🍪四层演进

一.初学者：单体架构，2012 年春运的"雪崩"

2011 年 6 月 12 日，12306 网站正式上线。第一张京津城际电子客票售出，拉开了中国铁路网络售票序幕。

当时的架构说白了就是单体应用直连数据库：

用户请求 → Web 服务器 → 应用服务器（单体）→ Oracle 数据库

余票查询、订单创建、支付处理，全堆在一个应用里，所有读写都走 Oracle。

设计能力是每天 100 万张。2012 年春运，实际日点击量冲到 14 亿次。

系统直接被干翻了。

余票查询请求像海水一样灌进来，网站入口堵死。更要命的是，各业务分区没做隔离，一个模块变慢，就把整个系统拖垮，典型的雪崩。

这里有个很多人没注意到的细节，铁路售票真不是"卖一张少一张"那种简单减法。

以京沪高铁为例，沿线 24 个站，任意两站间的组合有 276 种卖法。一趟车 1000 个座位，能裂变出上万种可售票组合。

你每查一次票，线上网站和线下车站窗口的电脑都要同步更新余票，否则就会一票多卖。

👽人话解释
想象一家有 1000 个座位的餐厅，每张桌子可以从第 1 站坐到第 24 站，也可以只坐第 3 到第 8 站。每卖出一张票，沿途中转站的所有组合库存都要重新算一遍。这不是"减 1"，是"减一整棵排列组合树"。

2012 年春运最高日售票量 120 万张，已经远超设计能力。

单体架构的根本毛病在于：所有流量不分轻重全涌向同一个数据库，查询和交易互相挤占资源，哪个环节慢一点，整条链子就连锁崩掉。

二.进阶开发：异步排队 + 内存余票计算

2012 年春运被教做人之后，单杏花团队干了两件大事。

第一件：异步交易排队系统。

思路其实很朴素：把海量、乱序的购票请求，整理成一条有序队列。

用户点"下单"，系统先快速校验身份和余票，符合条件的发一个排队号牌。后台按"先到先得"依次完成余票锁定、支付核验、订单生成。

用户不用死盯着页面等，可以查排队状态。系统根据核心算力控制处理速度，流量大就放慢提交，流量小就加快。

这套机制把承载能力直接拉高了 5 倍。

用户下单 → 快速校验 → 发排队号牌 → 进入MQ队列
                                         ↓
                         后台按序处理：锁票 → 支付 → 出票
                         （动态流量控制：根据AS响应时间调节提交速度）

👽人话解释
就像去银行，以前是所有人挤在柜台前抢着办，现在进门先取号，坐在等候区看大屏叫号。柜员处理得过来就快叫，处理不过来就慢叫，不会因为人太多把柜台挤塌。

第二件：分布式内存余票计算。

以前查余票，直接读数据库磁盘，响应时间 1 秒以上，高峰期查询能力不到 1000 次/秒。

团队把全国余票数据拆到多个内存节点，每个节点负责特定车次。算余票时直接定位到对应内存节点，不碰磁盘。

效果：

• 余票查询响应时间：1 秒 → 10 毫秒（快了 100 倍）
• 查询并发能力：1000 次/秒 → 20000+ 次/秒（提升了 20 倍）
• 余票计算从秒级突破到毫秒级，撑得住每秒数百万次查询

2013 年春运，优化后的系统扛住了最高日售票量 364 万张，是 2012 年的 3 倍多。

但麻烦事跟着来了：2013 年，第三方抢票软件冒头了。

三.高级工程师：分库分表 + 读写分离 + 售取分离

抢票软件的疯狂刷票，让访问量继续往上飙。2017 年春运，单日最高访问量到了 2600 亿次。

数据库又顶不住了。订单查询 TPS 只有 200 次/秒，高峰期用户查个订单都要转半天圈。

团队干了三件事：

1. 分库分表：1 节点 1 库 1 表 → 3 节点 30 库 30 表

-- 改造前：单库单表
SELECT * FROM order_table WHERE username = 'zhangsan';

-- 改造后：按 username HASH 分散到 3 个节点 × 30 个库 × 30 张表
-- ShardingSphere 透明化分片，应用层无感知

订单和电子客票数据按用户名 HASH 拆分，每个用户的操作落在固定的节点和库表上。核心交易处理能力跟着线性涨，后续还能继续横向加机器。

2. 读写分离：查询和写入走不同节点

订单和电子客票用内存计算 NoSQL 集中存储，对外提供 Key-Value 查询。

3. 售取分离：网上售票和线下取票互不干扰

售票节点 → 承载网上售票（下单、支付、出票）
取票节点 → 承载线下取票（窗口、自助机取票）

早先网上售票和线下取票挤在同一个业务节点上，高峰期互相阻塞。拆开之后各自独立扩展，谁忙谁加机器。

👽人话解释
读写分离像餐厅把"炒菜"和"传菜"分工，厨师专心炒，服务员专心传，互不拖累。售取分离更狠，直接把"堂食"和"外卖"分两个厨房，各做各的，谁也不堵谁。

这三板斧下去，极限交易能力到了 300 张/秒，够支撑日售票 500 万的需求。

四.架构师：混合云 + 双中心双活 + 风控体系

分库分表把数据库瓶颈解了，但春运流量洪峰带来的弹性需求还在。你不可能为了春运那 40 天的峰值，平时养着一大堆闲置服务器干烧钱。

架构师纠结的不只是"扛不扛得住"，还有"花多少钱扛"。

1. 混合云架构：私有云 + 公有云

                    ┌─────────────────┐
         ┌──────────┤  全局负载均衡 GSLB  │
         │          └─────────────────┘
         │                    │
    ┌────▼─────┐         ┌─────▼─────┐
    │ 铁路私有云 │         │  公有云    │
    │ (核心交易) │←专线同步→│(余票查询等) │
    │ 订单/支付  │  100Gbps │ 弹性扩容   │
    │ 席位管理   │  延迟<2ms│ CDN加速    │
    └──────────┘         └───────────┘

私有云承载购票、订单、支付等核心业务，数据在铁路内部服务器，安全可控。公有云承担余票查询、车次浏览这些非核心但高并发的业务，春运高峰能瞬时扩容几百台服务器。

👽人话解释
私有云是你的私家厨房，做核心菜品（购票交易），安全第一。公有云是春运期间临时雇的帮厨团队，专门做凉菜（余票查询），忙完就撤，不养闲人。两边通过专线实时同步，用户无感知。

2. 双中心双活：1 秒故障切换

同城建两个数据中心，配置完全一致，并行承载购票业务。任意一个中心过载或宕机，1 秒内流量自动切到另一个中心，用户基本无感。

再配合 18 个铁路局中心席位运维中心，搭起"集中 + 分布"的交易平台。

3. 风控体系：与抢票软件"斗智斗勇"

2013 年抢票软件出现后，12306 自研了风险控制系统：

• 动态调整验证码难度（滑动验证码、图标点触）
• 机器学习识别黄牛行为模式
• 对疑似抢票流量做拦截
• 每年拦截超 10 亿次异常购票请求

同时上了候补购票：只要候补队伍里有人，系统一旦发现退票产生的余票，优先给候补旅客。2025 年清明假期候补兑现率超 60%。

4. 智能调度：大数据预测运力

• 客流预测颗粒度压到"小时级"，准确率 97.3%
• 客座率突破 85% 时自动触发加开列车指令
• 1 小时内完成运力调配

从 2012 年的"雪崩"，到 2025 年扛住 2600 亿次/日访问、单日售票 2000 万张以上，12306 的架构演进经历了 6 次大规模建设改造、上千次功能优化。

团队也从最初 28 人的研发小组，长成了 700 多人的精锐队伍。

总结

别抄 12306 的终态架构，学它"渐进式迭代"的那股劲。

12306 这套演进逻辑，说白了就一句话：流量逼着架构改，架构改完又能撑更大的流量。

• 流量扛不住 → 引入缓存和队列（异步化）
• 数据库扛不住 → 分库分表 + 读写分离（数据层拆分）
• 弹性不够 → 混合云 + 双活（资源层弹性）
• 公平性不够 → 风控 + 候补（业务层兜底）

没有哪一层是提前规划好的，全是现实一巴掌一巴掌拍出来的。

你做系统设计时，可以先问自己三个问题：

1. 我的系统流量洪峰在哪？有多极端？持续多久？
2. 哪些是核心交易（不能错），哪些是查询（可以容忍短暂延迟）？
3. 我现在在第几层？下一层升级的触发条件是什么？

把这三个问题想清楚，比直接抄 12306 的架构图有用得多。

说到底，架构没有银弹，关键是分层和取舍。12306 这十几年不是一步到位设计出来的，是被业务压力一点点逼着迭代出来的。哪次"扛不住"，哪次就是下一次升级的开始。