每逢春运、国庆等出行高峰，12306网站“崩溃”“卡顿”“排队”等关键词就会冲上热搜。有网友不禁发问：在12306出现之前，线下购票柜台工作人员使用的TRS系统也是全国联网的，为什么那时没有崩溃问题？这背后，并非TRS系统“技术更先进”，而是两个时代、两种场景下的“降维打击”与“极限挑战”。

TRS系统：封闭专网下的“有限并发”

TRS系统（铁路客票发售与预定系统）诞生于20世纪90年代，是中国铁路第一个全国联网的售票系统。它确实实现了所有车站、代售点实时共享余票信息，与今天的12306同属“实时交易系统”。但TRS从未出现大规模崩溃，核心原因在于其业务环境的天壤之别。

第一，终端数量可控，并发量极低。 TRS系统的使用者仅有窗口售票员和代售点工作人员，全国窗口数量不过数万个。每一个终端背后是一个真实的人类操作者，售票员敲键盘的速度再快，每分钟最多处理2-3笔交易。即便在春运高峰，全系统同时在线终端数不超过10万，并发请求量峰值大概在每秒几百笔。而12306在春运期间单日最高点击量超过1500亿次，峰值并发请求可达每秒数十万甚至上百万笔，两者不在一个数量级。

第二，网络环境封闭，无外部攻击。 TRS运行在铁路内部专用网络上，不与互联网直接连通，不存在DDoS攻击、恶意刷票、爬虫等互联网流量干扰。系统稳定性仅取决于硬件和数据库本身，外部因素几乎为零。

第三，业务逻辑简单，无复杂缓存与排队。 TRS仅处理“查询-下单-支付-出票”的线性流程，且支付方式单一（现金或银行卡），不涉及第三方支付回调、动态票价、选座、改签等复杂逻辑。更重要的是，TRS不存在“动态余票计算”——票额在发售前已固定分配至各站，售票员只需扣减本地配额，跨站查询需调用远程数据库，但操作频率极低。

12306：互联网级的“史诗级”挑战

12306从2011年上线起，就面临全球独一无二的业务特性：

  • 高并发与动态余票：所有车次、所有站段的余票实时共享，且存在“复用票”规则（如北京-上海余票1张，但北京-南京也有票，需实时计算）。数据库每一秒都要处理数亿条级别的逻辑运算。
  • 秒杀级抢票流量：千万用户同时刷新，对服务器和数据库造成山呼海啸般的压力。
  • 占座与超卖：为了防止超售，系统需在用户下单瞬间锁定席位，同时处理未支付释放、退票回库等事务，对一致性要求极高。
  • 安全风控：识别机器人、刷票软件、异常IP，需额外消耗计算资源。

初期12306采用传统关系型数据库和集中式架构，根本无法承受如此量级的请求，产生了“死锁”“超时”“504错误”等经典故障。直到引入分布式缓存、内存数据库、异步消息队列、云计算弹性扩容等技术，并采用混合云架构将查询流量分流，才逐步实现“平稳度峰”。

不是TRS不崩溃，而是从未被“攻击”

简而言之，TRS系统之所以“从不崩溃”，是因为它的用户是售票员，而非14亿旅客。它的联网是“有限节点互联”，而非“全网开放并发”。如果将12306的流量压力施加到TRS上，TRS瞬间就会瘫痪——因为它根本没有设计应对每秒百万级请求的架构。

反过来，如果将TRS系统直接搬到互联网上，那将是灾难：人工售票的交互速度、线性扣票逻辑、无缓存设计，根本无法支撑哪怕十分钟的峰值流量。

结语：技术进步让服务更易，也让运维更难

今天的12306已经能够承受春运1500亿次点击而不崩溃，背后是分布式、容器化、多云协同、全链路压测等现代工程能力的体现。TRS系统则早已成为历史，但在那个只有窗口售票的时代，它从未“被崩溃”，因为它的敌人从未真正登场。当我们抱怨12306卡顿的同时，或许也该意识到：能让数亿人同时买票的系统，本身就是世界级的技术奇迹。