摘要：Java精选面试题 （微信小程序）：5000+道面试题和选择题，包含Java基础、并发、JVM、线程、MQ系列、Redis、Spring系列、Elasticsearch、Docker、K8s、Flink、Spark、架构设计、大厂真题等，在线随时刷题！

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

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

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

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

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，似乎是阿里团队的技术太牛逼，所以改变了 12306 经常崩掉的局面。但看了这些回答，我才发现，原来中国计算机领域最牛逼的还是通信部和铁道部。

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

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

公众号“Java精选”所发表内容注明来源的，版权归原出处所有（无法查证版权的或者未注明出处的均来自网络，系转载，转载的目的在于传递更多信息，版权属于原作者。如有侵权，请联系，笔者会第一时间删除处理！

Java精选面试题（微信小程序）：3000+道面试题，包含Java基础、并发、JVM、线程、MQ系列、Redis、Spring系列、Elasticsearch、Docker、K8s、Flink、Spark、架构设计等，在线随时刷题！

文章有帮助的话，点在看，转发吧！

来源：拿趣黑科技