12306没崩过？聊聊线下购票TRS系统为何“稳如老狗”

最近在知乎上看到一个挺有意思的热门话题：“在12306出现之前，线下购票柜台工作人员使用的TRS系统也是全国联网的，为什么那时没有崩溃问题？”（原帖链接：https://www.zhihu.com/question/572076661）。很多年轻朋友可能都没见过火车站售票窗口后面那台跑着TRS的绿屏终端，但经历过春运排长队买票的人，应该都对它有点印象。今天我们就顺着这个问题，把背后的技术逻辑和时代背景掰开说说。

先搞明白：TRS到底是什么？

TRS全称是“铁路客票发售和预订系统”（Ticketing and Reservation System），从上世纪90年代开始逐步推广，到后来实现了全国联网售票。它确实和12306一样，是中心化、联网式的系统——你在北京买上海到广州的联程票，后台也要查异地余票。

但和现在大家手机点12306不同，TRS的“用户”不是几亿旅客，而是全国几千个车站、上万个售票窗口的铁路职工。每一个操作请求，都先由售票员在本地终端录入，再传去地区中心或铁道部数据中心。

为什么TRS很少听说“崩了”？

1. 并发量完全不在一个量级

12306高峰时每秒要扛几十万甚至上百万的点击和查询，而TRS时代，全路同时操作的窗口顶多一两万，且每笔交易还要人工敲键盘、收钱、打票，一笔少说几十秒。系统实际每秒处理的事务（TPS）可能只有几百。这种负载，当年的小型机完全Hold住。

2. 请求是“窄管道”，不是“洪水”

TRS终端通常只传极简指令：车次、日期、席别、张数。没有图片、没有动态余票地图、没有抢票脚本。网络带宽占用极低，后端也无需做复杂的前端渲染。

3. 没有“全民瞬时冲击”

过去买票要物理排队，窗口开放时间固定，客流被空间和时间强行削峰。春运再难，也不会出现“同一秒一千万人同时戳一个按钮”的场面。而12306面对的是公网开放、随时可刷新、外挂横行的环境。

4. 系统边界清晰，故障影响局部

TRS如果某个地区中心出问题，往往只影响该片售票，且可切回离线应急售票模式（卖手工票或本地缓存）。而12306是全程在线强一致，一旦核心集群异常，全网用户都能感知。

补充一点容易被忽略的上下文

其实TRS早年也出过故障，只是传播不像今天这么快。2000年前后，个别车站因网络中断只能用备用金和手工票，但旅客感知是“窗口停售”，不会说“铁路系统崩了”。另外，TRS的数据库设计以事务强一致为主，余票扣减靠后台锁定，没有后来互联网高并发下的分布式缓存难题。

反观12306，它不仅要解决“卖票”，还要防黄牛、做候补、扛峰值查询，技术复杂度是指数级上升。后来12306引入异步队列、余票缓存、混合云，才逐步告别“逢节必崩”。

小结

说白了，TRS没“崩”不是因为当年技术多神，而是使用模型决定了压力可控。12306的崩溃焦虑，本质是“全民互联网化”带来的全新工程挑战。理解这段历史，也能少一些对老系统的浪漫化，多一些对现代票务系统复杂度的客观认知。

如果你也排过TRS时代的购票长队，欢迎在评论区聊聊当年的故事。