中国的铁路订票系统在世界上属于什么水平？ | 芋道源码 —

阅读全文

⭐⭐⭐ Spring Boot 项目实战	⭐⭐⭐ Spring Cloud 项目实战
《Dubbo 实现原理与源码解析 —— 精品合集》	《Netty 实现原理与源码解析 —— 精品合集》
《Spring 实现原理与源码解析 —— 精品合集》	《MyBatis 实现原理与源码解析 —— 精品合集》
《Spring MVC 实现原理与源码解析 —— 精品合集》	《数据库实体设计合集》
《Spring Boot 实现原理与源码解析 —— 精品合集》	《Java 面试题 + Java 学习指南》

摘要: 原创出处 www.zhihu.com/question/315887668 「网络」欢迎转载，保留摘要，谢谢！

🙂🙂🙂关注微信公众号：【芋道源码】有福利：

RocketMQ / MyCAT / Sharding-JDBC 所有源码分析文章列表

RocketMQ / MyCAT / Sharding-JDBC 中文注释源码 GitHub 地址

您对于源码的疑问每条留言都将得到认真回复。甚至不知道如何读源码也可以请教噢。

新的源码解析文章实时收到通知。每周更新一篇左右。

认真的源码交流微信群。

中国的铁路订票系统在世界上属于什么水平？

没错，就是世界第一，而且极其牛逼。我很佩服设计这套算法和系统的人。

我们来看看知友们都是如何评价我国铁路订票系统的——也就是大名鼎鼎的 12306。会非常有意思。

先来看看这个 1.8 万赞的，我觉得说得非常有道理（狗头必须加上），所以也趁机点了赞。

我只能告诉你，12306，曾经出价10亿，如果不够，可以加，让他们稳固系统，保证大家订票不出问题，结果，全世界最顶尖的计算机团队，折腾几个月，最后结果是，可以解决，但是，解决代价嘛，就是，多加服务器

12306想了下，为了春运与那些节假日这几天，加服务器，不划算，后面也就算了，因为，这种行为跟面子工程差距真的不大

大不了这就，多请点维护人员，大家轮班。

这么说吧，火车站的电脑，需要最高权限，也就是，实时刷新，并且还要预留余票，因为，很多人，并没有网上订票的习惯

这是，基础设施，不能寒了这些人的心。

我国，春运时期，用12306买票人数，估计有8亿，什么概念，并且，12306，保证所有人，没有出错！！！！！

这个水平，丢在国外，那就是神话！！！！

再加上，我们那些抢票软件，能够造成一个人刷新10-1000次的访问率甚至更高

也就说，如果这8亿每个人使用抢票软件，最高的刷新率，能够造成8000e的访问记录

然后访问出来了，要买票，这个买票这个动作。要同一时间，确认票，购买票，删除该票的存在（不能重复购买），而不是像双十一，你们先买，订单到了，我再确认仓库，再发货，这就错开了流量峰值

而12306，两个字，实时！！！

8000e，你问问腾讯，阿里，能不能承受！！！！再把这个数值乘上3，能不能搞定这么大流量

要保证不出错，已经很不错了，因为，如果同时买了同一张票，他会自动更改为其他位置，毕竟一个位置只能做一个人！！！

12306是全世界最强网站，没有之一！！！

好多知友喷的：

这回答也太业余了吧。。。。。
你，为什么，要这样，说话。这样子，说话，看的，很难受
12306最难解决的是座位（库存）的架构和扣减的问题，瓶颈并不是在服务器上。如果您不是业内人士，最好不要误解他人哈。

但当我看到这些评论都是作者自己加精后，我似乎悟了，这分明是作者在钓鱼。。。。。

再来看看认真答题的，比如说 liujunsong：

非典那年机缘巧合之下，做了个哈尔滨铁路分局的信息化项目，当时从侧面了解了一些铁路订票系统的故事，因时日太久，到底是当时的真实记忆，还是想象补充，都已经无从考证，这里只是写出来仅供参考讨论。

首先以前在铁路信息化之前，票务系统可以说是一片混乱，由于铁路客票一票难求，因此有无数黄牛以此为生，客票是不记名的，也给黄牛带来了滚滚生利。当时采取的对策，主要是采取保留票制度，例如北京发上海的车票，假设有10个车厢，那么中间途径济南南京两个大站的话，那么就给济南站留一个车厢，给南京站留一个车厢，这两个车厢北京站只出售短途车票，不售卖到上海的。这种票务分配是基于政策的，各个车站之间没有联网，互不知晓。

到了90年代，哈尔滨铁路局主持开发了全国第一套基于sco Unix 的，使用c语言开发的票务分配系统，在主机上将客票按照规定的策略将一趟车的所有客票进行分配，就是将上面的逻辑用程序实现。同时各车站加入了抢票功能，先把自己可以售卖的车票抢下来，再按照需要售卖给外面等票的人。

这是一个划时代的成果，在当时的网络条件下，采用上下位之间的通讯，实现了针对车站的订票，售卖，退票功能。当然还有后续的结算功能等等。这套系统是基于小型机开发的。这里车站和票务中心的通讯不是实时的售卖，而是在指定时间点，各车站先把自己能发售的票抢出来，下载到自己的本地服务器上，再在自己这个服务器上一张一张出票，卖不掉的票可以在一定时间段退回去，或者根据…【人工调度命令】把票退回去。

当时听到这个故事的时候很震撼，但当时不懂东西太多，无法理解他们是怎么做到的。

后来到了2000年左右，由于微机价格低廉，应用系统开发到了cs阶段，上面这套系统升级到了cs阶段。客户端用的是pb或者vb ，数据库用的是sybase，中间件选用的是tuxedo. 当时见过这个售票系统的界面，应该是pb开发的。当时仍然采用的是分布式的部署架构，各铁路分局部署自己的售票系统，再通过服务器从总的票务中心下载票务数据，批量订票，再到各个车站出票。这时各个铁路分局所属的各个车站逐渐实现了内部联网。当时联网用的好像是adsl拨号技术。

这套技术应该说很稳定的运行了十几年吧。

至于全国大集中的12306系统出现。

与一般人的理解完全相反的是，各种应用系统其实一开始都是大规模分布式的，尤其这个整体票务系统，一开始是大概三层的票务系统，铁道部一层，各铁路局一层，分局一层，车站一层。各层之间进行数据包传递来协同工作。这个和银行系统也有类似之处。

后来随着信息化的扩展，大约用了二十年的时间完成了大集中。银行业大约是2000年左右实现了全国大集中，央行大约是2010年完成了大集中，代表成果就是二代支付系统，大小额接入系统这些。而铁道部的大集中基本上是在12306之前就完成了，大约也是那个时代的产物。

中国的信息化有着自己鲜明的特色，就是大集中。这个有着行政上执行便利的考虑，也有人们思维惯性的考虑，这里就不细说了。

从这个意义上来讲，只有在中国现有的条件下，才有可能建立一整套的大集中系统，而这在其他地方是不具备条件的。

别的不说，光客票系统直接和公安的人口信息系统连接，在很多国家都是不可能完成的任务。因为绝大部分国家根本没有完整的户籍管理制度。

想当年也是20年前了，曾经接触过一次飞机票的代理系统，当时每个代理点需要拉一条专线到航空公司的票务中心，然后利用telnet登录上远程终端。通过在终端输入命令，来完成飞机票的订票交易。当时订票的逻辑就是先可以锁定一张机票，然后再进行一次确认，或者把这张票退掉，如果超过锁定时间，可能会被强制退掉。这样就有以下几个交易代码：查询，预订，确认，取消。这套票务系统是全球通用的，后台是一套大机系统，然后通过层层分布的前置机推广到全球来使用。这套系统的开发时间，应该是上世纪七八十年代了。

那次交流的时候，订票点给我们详细介绍了飞机票的订票全流程。因此在后来又听别人介绍火车票的订票流程的时候，才有这样的共同点存在。

现在的人一想到票务系统，出于惯性会认为那个系统一定是基于数据库的，然后就掉到事务，数量这些细节里面了，不能自拔。其实最早期的票务系统是基于文件和报文来处理的，那时可能都没有成熟的数据库系统存在，因此也就不存在现在困扰大家的数据一致性问题和事务管理问题。而如果是完全基于文件系统来设计和开发票务系统，那就会走向完全不同的一个架构体系了。

其实，12306 牛逼主要有以下三点：

所销售商品极其复杂（SKU极多）
商品和商品之间、横跨全国的渠道之间，都相互干涉
访问量极大

印象中，总以为是阿里的淘宝团队改变了 12306，似乎是阿里团队的技术太牛逼，所以改变了 12306 经常崩掉的局面。

但看了这些回答，我才发现，原来中国计算机领域最牛逼的还是通信部和铁道部。

据知友所说，国铁集团下属的铁科院电子所，领军的牛人叫单杏花，是 12306 的最强大脑。

所以说，小伙伴们有机会的话，可以考虑考虑铁科院电子所。。。。。。