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

源码共读

共 3267字,需浏览 7分钟

 ·

2022-07-31 07:13

👇👇关注后回复 “进群” ,拉你进程序员交流群👇👇


来自公众号:沉默王二
综合自知乎:
https://www.zhihu.com/question/315887668


大家好,

今天分享的这篇:中国的铁路订票系统在世界上属于什么水平?

我们来看看知友们都是如何评价我国铁路订票系统的——也就是大名鼎鼎的 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极多)
  • 商品和商品之间、横跨全国的渠道之间,都相互干涉
  • 访问量极大

大家对这个问题感兴趣的话,还可以通过下面这个链接去看原贴哈。

https://www.zhihu.com/question/315887668

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

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

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

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

-End-

最近有一些小伙伴,让我帮忙找一些 面试题 资料,于是我翻遍了收藏的 5T 资料后,汇总整理出来,可以说是程序员面试必备!所有资料都整理到网盘了,欢迎下载!

点击👆卡片,关注后回复【面试题】即可获取

在看点这里好文分享给更多人↓↓

浏览 12
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报