12306 是不是现在世界上业务逻辑最复杂的系统之一？

[justrand]

光想想这并发量头就发麻，不像天猫双十一是短时间并发，12306 是一出票就双十一。

稍微理了下思路：
火车票是一个基于库存又需要 100%正确（也看到过报道一票超卖的现象我不知道是不是真的）的销售，同时还有神奇的乘车区间合并拆分以及车票的排列组合，光是想想就很困难呀<br>

[admin7785]

一张车票很多区间，可以裂变出很多可能，要想做到利益最大化，这个逻辑我不敢想，也不会

[QNLvw5fLfr7c]

有理有据的论述，就算是犯了错误或是说明不充分，也是应该尊重的。
而上面冷嘲热讽的、不看后续讨论不假思索便就回复的、以及人身攻击的，占了一半楼层。

[railgun]

单论业务逻辑，我觉得最复杂的是 windows

[tianshilei1992]

@20150517 一列 K 打头的车几十站…

[SlipStupig]

大家要分几个层面看问题。

- 12306 这套东西大家都没考虑到它的历史包袱，最早的是时候为什么那么慢那么难用，是因为最早的 12306 是一个内部版本也就是以前在代售点那套系统，这套东西和铁路调度系统是强绑定的，当时 12306 是双系统制，外部下单相当于多了几个亿的火车票代售点，然后去提交，但是实际情况远远超过了当时铁总设计的预期，所以被骂的要死。
- 业务复杂度从最基本的票务类型开始算就很多类型：团体票、个人票、学生票，然后依次是座位类型和价格要进行动态计算价格，然后上架库存（觉得不以为然的自己可以尝试一下），然后就是噩梦的开始，用户一旦刷不出来票来就会拼命的刷新，本身就高负载遇到更大的压力，然后票务面临退改签这个过程要保证尽量不要出错，而且还要快速响应，确认作为后还要跟铁路系统对接，这个东西复杂度难以想象，当年只花了 3 个亿能做成已经相当不易。

[ooh]

好奇 12306 是怎么设计的？预先根据各个区间生成座位，然后客户端秒杀座位？？区间越大优先级越高？？？因垂丝汀，翻了这么多楼为什么没看到哪个聪明鬼讨论这个🤣

[dangyuluo]

我昨天还喷了 12306😂知道不容易，但是也是很无奈

[bullfrog]

之前死去活来的，阿里派一个团队第二年就马上改善了，你说是简单还是复杂。。

[aheadlead]

https://sm.ms/delete/CGvz1tdrS95Fm8jOlawPDUgBns

[aheadlead]

贴错了…



供大家参考

[zhihupron]

12306 是导师让学生做的。大头导师赚了。

[zzxCNCZ]

@fancy111 如果像你说的大家都手工去买就好了，实际上都是各种抢票软件

[m939594960]

虽然我水平烂，但是我还是要说如果给我那么些钱，我做出的东西绝对比 12306 牛逼，就 12306 那破 APP，那破网页（没改版之前点击操作都会卡住）

还有 12306 这么大的系统不是应该竞标的么？没那个本事就别接啊。


说个最浅显的东西：
1.冷热分离，那些火爆的线路就让它火爆吧，其他的线路是不是应该不受这些火爆线路的影响？个人中心是不是不应该受影响。
2.每日维护，请问一天维护 6 个小时，这 6 个小时要干啥？
3.那些说没超卖的请查查新闻好么？
4.那些说实时显示的先自己买个票好么？


其实我觉得可以说他复杂，但是做到这个程度大家都应该知道做这个系统的人什么水平

[wangyifei6817]

@m939594960 你是刚毕业还是是 2#的马甲啊?
随便查查这几年的资料都说不出这些话啊 兄弟

[nicevar]

@Building 无知，站着说话不腰疼，当年没有网络售票的时候你知道有多惨吗，北京西站一大堆人连续好几天通宵排队都买不上票，还下着雪，大家就站在雪地里挨冻

[m939594960]

@wangyifei6817 #214 嗯，如果有想反驳的请反驳，不想反驳就请别回复，你这样的回复并没有什么实际意义！

[hercat]

@iccfish 捕捉鱼佬

[csidez]

@JunoNin 哈哈哈哈，就你回对最新奇。上面评论看下来，你是茫茫汪洋中对一帆小舟

[wulin]

先不谈买票，卤煮可以试着设计一个余票查询，这个复杂度就很高了 /doge

[openbsd]

@LuciferGo #95
可能逻辑没那么夸张，每个始发站的售票时间不一样
而且最多只能预定 半小时？ 之后开出的车次，
下车的情况，不是售票的时候就知道了？

[root8080]

喜欢这样的帖 大家发表自己的真知灼见 （也许是错的但是哪有怎么样呢 看的很有味道啊！ 大家和善一点嘛 说归说骂人的话就不要了

[gamexg]

@Ncanback #182

单纯技术讨论

出现过长途有票但是中间区段无票的现象，
可以认为票是预先分配到区段票池的，而不是买票时实时计算合并拆分区段的。
区段拆分可以后台去执行。

那么现在这个买票请求就直接变成了可以水平拆分的情况了，单纯买票的票数控制部分近乎无限扩展。


我只说下觉得比较简单的实现方式：

a-b-c-d 这么一个线路，上线时预先根据之前的运营经验，分配好 a-d、a-b、a-c、a-d、b-c、b-d 等票段的票数。
为了方便后期调整，可以考虑 a-d 段多预留票数，售票中发现 a-d 余票比较多，可以后台拆分 a-d 的票。

数据库部分可以用 sql 数据库或 kv 数据库，
key = 起始站、终点站、时间、车次、座位类型
value = 剩余票数

查询余票信息直接就是一个主键查询了，修改余票信息也只是原子减操作。

对于压力问题，极限情况下可以做到这么一条记录一个数据库，不太相信撑不下来。
如果单个条目一个数据库还撑不下来，那么也好处理，再增加几个缓存数据库放在前面。web 服务器去取票时，从缓存数据库取，缓存数据库无票时缓存数据库再去主数据库取票，一次取 100 张票，那么就可以将主数据库的压力降低 100 倍。

当然是及上需要考虑很多细节，例如拆分为了太多数据库维护上会比较麻烦。
上了缓存数据库，那么可能出现这次查询时用的缓存没票了， 但是实际其他缓存还是有票的。

不过实际看知乎上面参与开发的人员回答，目前的问题是实际票务数据是分别保存在不同铁路局，出票还需要去操作各个铁路局的数据库。这种情况下我觉得问题不是出在技术上面了。

[338c]

我猜 这个停机维护 是不是更新每天的热数据啊
猜每天要卖的票肯定有上限 假如用最快的存贮介质去存 比如 RAM 票有上限 RAM 就有上限 RAM 上限之后 程序生成一次或者插入 RAM 是不是也需要时间 限制与交互网络 和 其他的一些等等 插入的数据 是不是要需要效验一遍正确性 TB 级或者更大的 RAM 数据插入 效验 是不是需要更久的时间
... ....

[iMusic]

复杂确实很复杂，但不妨碍它做的就是烂

[Myprincess]

我觉得应该提高取消扣款率。车票 100，取消一次，扣 80 块。第二次购再取消，直接扣 100%。
重复订票手续费用。如果买广州到上海的，15 号买了票，你想再买 16 号广州到上海的直接加价 300%。

[SurfaceView]

@woodensail
“不是，12306 这个也就是个普通小电商秒杀的水平。 ”

学习了

[smdbh]

其实有很多技术或是规则上优化的地方。 那最后计算量就没那么大了。
在硬件水平有限的情况下，单纯的拼 crud，和写冒泡排序有那么点类似

当然忍不住透露下，以后大家都上 5g，抢票就不存在了，

[zxcslove]

平衡问题：
高科技资本和大众之间
熟练玩家和普通群众之间
线上群体和线下群体之间
列车经过不同地域之间
............
完全只考虑线上售票，只从效率考量，哀鸿遍野，画美不看

[youngster]

@woodensail 你已经被 block，真的是哪里都想插一脚，哪里都想说两句？您真是不懂专业二字

[woodensail]

@youngster 心平气和的讨论技术问题不好吗？

[ech0x]

不是，日本的新干线系统远比这个复杂。

[palexu]

@ifxo 你以为阿里没去？阿里去了，没搞定好吧。说话之前先去查查资料，别想当然了。光 12306 那个内存数据库你就搞不定

[palexu]

@woodensail 承包我今日笑点

[youngster]

楼上那位说的对，不仅仅是网上售票的并发量，还要考虑各个站点，代售点票务系统的对接（全国多少个点不敢想象），光是同步的数据并发就很大了，而且考虑到站票、坐票、软硬座；站次、加仓、区间站，我觉得是复杂度前几的需求了。而且想想中国铁路的体量和国家牌面，这么多年不曾涨价的底气，我觉的他的票务系统一定不差钱也不差人；但是目前还是有很多问题和不理想的地方，足以说明复杂和困难仍然很多。

[palexu]

@lihua1358 舍不得花钱？先去查查他们用的几 t 的内存的机器要多少钱

[across]

这算是年经贴了····

年年喊 12306 高峰崩溃不改，改了又能咋呢，票本来就不够，多开服务器给你登上去，无非多瞅下空票，能抢到票还是并发抢在前面的人。 想着不崩溃就好无非是不见棺材不掉泪。

[woodensail]

@palexu 哈，年末了嘛，多划划水。

[Ncanback]

@gamexg 如果是按照你所说的 那么每天晚上停止服务 应该就可以理解为 夜间各个铁路局自己的票池统计并汇总，制定第二天的出票数。同时在第二天产出“新”的票进行售卖。那这也太蠢了........

[yaoye555]

我可以这么理解么 这个贴明年这个时候拿出来依然可用, 事实证明 12306 改动的挺大的, 至少我俩年前写的爬虫脚本 现在已经不能用了[doge]

[helionzzz]

@maokwen 我就想知道 12306 这个也就是个普通小电商秒杀的水平这句话有理有据在哪？ 不吝赐教。

[jun0205]

12306 的问题不在 web 查询上面，复杂的是支撑整个 web 后面的架构。大部分人都不了解铁路售票系统是什么样的，在这谈 web 怎么样。

[subpo]

只是说业务逻辑的话还好吧...复杂是复杂的，还不至于最复杂

[youweiks]

[https://cloud.tencent.com/developer/article/1419515]( https://cloud.tencent.com/developer/article/1419515)

[lysS]

@woodensail 别说卖票了，设计一个让火车在有限的轨道上同时运行，不撞车，还最高效的系统吧，别的不说。。
参考回形针怎么调度列车
https://www.bilibili.com/video/av42125169

[Epsil0n9]

@m939594960 #213 現在国内制度一向是利益为主,能力次之

[Epsil0n9]

@wangyifei6817 #214 每个人都有他的信息局限性,直接提供有效信息更有意义. 否则人之间就很难互相借鉴,也很难有说明力

[elfish]

比如 a-b-c10 座，初始 a-c,a-b,b-c 各最大 10 张，如果有人买 a-b，那 a-c 和 a-b 各减一张，这样成不，所有搭乘可能票数最大化，售出的时候把影响的线路一并减掉。另外，技术不行能不能搞成摇号啊，比起等半天卡死，抽空预约等摇号，摇中直接付费，没付费的票下一轮摇号，至少乘客买票轻松点。补充：一般不乘火车，刚问了下，好像买票的时候可能是涉及到多次列车的换乘，这样的话卖出一张票影响的路线就指数级增加了，难度大概在这吗？

[linuxgoat]

2019 年春运从 1 月 21 日开始，3 月 1 日结束，共计 40 天。经预测，春运全国旅客发送量将达到 29.9 亿人次。其中，铁路 4.13 亿人次，民航 7300 万人次，水运 4300 万人次，与上年基本持平；道路客运受高铁通车里程持续增加、民航航班加密和私家车出行量快速增长等因素影响，县际以上班线客运量继续呈下降趋势，但农村客运、定制客运将继续增长，预计道路客运达 24.6 亿人次。

2020 年 30 亿人次的春运总量中，道路客运 24.3 亿人次，同比下降 1.2%；铁路 4.4 亿人次，同比增长 8%；民航 7900 万人次，同比增长 8.4%；水运 4500 万人次，同比增长 9.6%。高铁、民航、私家车等出行方式在春运中的占比持续上升。

每年坐火车的人数大概是 4 亿多人次，平均到每一天，大概是一千多万，还分布到全天不同时间段卖票，实际并发量没有特别高（没有达到上亿人同时抢票的程度）

[rizon]

@woodensail #2 我觉得 2 楼说的有些道理吧，12306 系统的难点肯定是有的，但不至于问鼎巅峰吧。。。。

并发上我觉得问题确实不大啊，整体很多，但是具体到一个车次人数就没那么恐怖了吧？
再者，12306 的票都是分批次的定期放票，因此我们可以假设他们的票是固定分区间销售的，每天晚上维护的时候再重新根据销售情况去重新分配各个区间票，和同步各个服务器的数据，少了动态分配的问题，就再次降低了并发的各种疑难杂症。。。

换言之，12306 我觉得是从营销策略上来解决了分布式和并发的问题，是大家把 12306 想的太高级太神秘了，不自觉潜意识的认为是有黑科技支持，但其实反而是用了最简单粗暴的方式去解决问题 。。

难道是我想简单了？？？？

[i36lib]

很多表面上看是技术问题的问题，事实上并不只是技术问题这么简单，各种流程、利益纠葛。

[python]

比 Google 复杂？

[5G]

你好，不是的，证券交易系统才是目前世界上业务逻辑最复杂的系统。

[leiuu]

@aheadlead 平时这些票可能卖不完，春运的时候应该会动态调整吧，不然冷门票可能都卖不去吧。

[leiuu]

@aheadlead 另外这个图里没有体现区间票，比如 a-b-c-d，b-c 的票数，这块不知道是如何分配的

[pythonee]

应该不仅并发的问题吧
线路，排班，站点工作协调等等
12306 是个出票窗口，但铁路系统应该比较复杂

[xinxijishuwyq]

@leiuu 每个段这次最多售多少是提前定好的吧。。。全程有票区间无票不是很常见