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

[justrand]

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

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

[a22124497]

@woodensail 秒杀是固定库存，车票可不是，ABCD，你买了 BC 的，A-C，AD，BD 的就不能卖了
实际情况肯定不止我说的这么点了

虽然我是个大菜鸟，但你说这话，也是相当之菜

[killerv]

12306 就是个普通小电商秒杀的水平
--------------
真是大言不惭

[zushi000]

我感觉挺难的，跟打地鼠一样 一个变了统统都要变。而且不光是线上。线下还是有网点，他们的存票又跟线上的不完全一样。

[woodensail]

@a22124497 看看前面的讨论吧。

[xunmeng1325]

我觉得抢票应该还好，铁路的路径规划调度才是最复杂的吧。

[ahaxzh]

关于上面有朋友说同一趟列车多种 起始——终点的问题，我觉得可以穷举打表。而且我觉得他们肯定这么搞了，因为量没有那么大。构造好数据结构，分布式布置到多台服务器上。所以核心的服务器压力应该没有那么大。

主要需要问题，应该还是处理并发请求吧。

纯粹个人瞎说，别当真。

[gamexg]

>同时还有神奇的乘车区间合并拆分以及车票的排列组合，光是想想就很困难呀

应该不是实时拆分，
听说过需要的区段买不到票时买全程的票却可以买到，
看起来每个区段的票是预先划分好的，至少不是买票时实时划分的。

[ahaxzh]

而且 12306，真的没有搞动态分配这种事情。每年购票的时候他都是事先预留好某种区间的票多少张这样，并没有说 这个区间这个时点买的人少，就动态的分配给另一个区间。这也就是为什么每年我买票的时候买区间票买不到，买全程或者 买到终点、从起点买就能买到的原因。

害怕被打，你们还是当我瞎掰好了。

[ahaxzh]

@gamexg 对，就是这个问题，所以我觉得他肯定是穷举了所有区间，然后分配票到各个区间去的。

[DonaldY]

看样子韭菜又长高了

[manami]

@woodensail 无知真可怕

[azuis]

@ahaxzh 动态分配是有的。区间限售一般是发车前两天才解开。现在还是优先照顾长途旅客。

[woodensail]

@manami 与其嘲讽，不如分享干货

[ahaxzh]

@azuis 这样啊，我还以为真的就是 老百姓说的 不卖短途票呢。因为每年我抢票，到小地方的票都没有，每年我要么从起始站买，要么买到终点站，一准买得到票。。2333

[ahaxzh]

逼乎有以前的回答： https://www.zhihu.com/question/27321479/answer/37292320

@woodensail

大家可以参考一下。

[wlzcool]

@ahaxzh 最后几天的时候就放开短途票了，先保证长途的

[liaoyaoheng]

对比证券交易兄台那个和双十二的 taobao.com 如何？
@xiasohan

[woodensail]

@ahaxzh 哈，看到过，我上面说的基本上也是这些，其实都是讨论过多少遍的东西了，这边还拿出来说，也就是 v2 没有知乎那样的话题合并功能了。

[7654]

春运是全球最大的人口迁徙
目前只有 12306 的系统能覆盖到很大一部分
汽运航运的系统也只能甘拜下风

[xiasohan]

@liaoyaoheng 说实话不太懂证券交易，，个人感觉要比双十一的困难一些

[windplume]

每趟列车的售票都是一个小电商，我感觉这比喻还差不多。

[manami]

@scnace 阿里之前有个程序员就是讥讽 12306 做得很烂，然后他自己试着实现发现真是难上加难，最后不得不感叹 12306 是个奇迹……

[b1u2g3]

又到暴露 v 友水平节目了

[Rorysky]

堆 内存，听说内存 好几个 TB

[8hfq]

作为专业抢票大数据开发人员 光我们这里的并发和逻辑就很复杂了 12306 应该更复杂

[DarrenLuo]

不说多了，阿里接手做了好几年才有了现在这个样子，说简单的就看看就行了

[tab16360]

@woodensail 满屏我就看你，“其实不难，因为一个车次视为一个整体，也才 1000 张票，压力不大。”
。。。。。咋滴？上了车还不让下了？

[Narcissu5]

不需要做 24 小时高可用，一到晚上就关系统，说实话只要可以停机难度下降一个数量级

[simo]

这个故事应该是：有个大佬把现在 12306 的详细业务梳理出来，让 hello world 们不要闭眼摸鼻子摸腿摸耳朵

[golden0125]

这是个好问题

[woodensail]

@tab16360 看看前面有人贴出的知乎回答吧，那个是开发者的答复。

[qiutianaimeili]

@woodensail 大佬这么厉害，能给我抢两张票码？

[woodensail]

@qiutianaimeili 哈，那也得你敢给身份证啊

[xxdd]

V2 现在这么无知者无畏了吗···

[sunziren]

@woodensail 大兄弟我佩服你

[woodensail]

@sunziren 哈，讨论讨论嘛，讨论得多了总是能有成长的。

[cnyang]

仅以单一业务逻辑来看，任意个能称得上人工智能的计算都可超越 12306，但要算上并发请求后的总量来看，的确可以排第一

[arthas2234]

膜拜各种大佬分析，我觉得可以去给 12306 设计一套合理的方案，人家肯定会重金酬谢

[nnnToTnnn]

12306 做的就是垃圾。 什么，你说的不是前端是后台，那当我没说 >>_<<

[nekoneko]

先别说了，我票抢不到，谁给支个招，bypass，携程，飞猪，手动，都只能抢到候补的。

[wolfan]

12306 最大的问题是基数过大，也就是体量积压。

[Amyclarence]

不是并发的问题吧，买票并发容易，但是 12306 还要动态排票处理下面的请求，不像电商买到就是买到了，一个用户秒杀到商品 A 只影响库存数量，有没有区间的概念，这是两种不同的复杂

[FS1P7dJz]

@Narcissu5 你这个说法并不准确
不如说是因为系统太过复杂,无法实现 7*24 不停机维护

不过需要注意的是,我没记错的话,12306 维护时间有缩短,技术还是在进步的

[est]

# 62 楼的 zhihu 链接已经说了

> 余票查询 访问量巨大，占 12306 整个网站流量的 90%以上，业务高峰期并发请求密集，性能要求是整个业务系统中最为重要的一环；

> 产品是 VMware 的 GemFire，据说用了十几个 T 的内存...这样查票（读，互联网内存库）和买票（写，铁路内网）就不在一个库了，至于显示有票但是买不到，那是因为两个库因为不在一个网络定时同步的时间比较长而已。


其实我觉得这个并不复杂。。。。你要说全国具体到某单一个车次的余票查询其实压力没那么大。也就几十万人同时刷而已。而且火车票有同价的站票是可以超售的。甚至有些车次超售得开不动了。

要说真压力大我觉得并发几千万的 RTB，万人群聊这些压力更大。。

[loryyang]

如果要完美确实非常复杂，但是目前的系统，并没有很复杂。因为这个系统不需要做到完美。比如你 ABCD 沿途的票，他每段可以预设一定额度来买，反正肯定卖的光，只要大致合理就可以了

[bolide2005]

@est #141

“甚至有些车次超售得开不动了”

不知道我们说的是不是同一个新闻，不过一般这种事好像和超售关系不大，都是“买短坐长”产生的恶果：买了短途票，上车补成长途票，结果后半段的人挤不上去了

[gamexg]

@Amyclarence #142 区间不知道目前怎么做的，

感觉有个偷懒的办法，例如 a-b-c-d 四个站的线路。
可以考虑预先分配好好票，a-d 保留大部分票，a-b、a-c、b-c、c-d 等等先分配少量的票。
售票时只用查询预先分配的票池，不要去处理合并拆分区间的问题，这样买票实现上就比较简单了。

然后后台定时去检查各个区段的余票信息，如果某个区段票耗尽了，可以根据需要拆分 a-d、a-c 等的票填充到各个区间。这里是后台操作，性能压力就不会那么大了。

不过看知乎里面的介绍，目前最大的问题可能还是历史遗留问题，票务数据还在各地铁路局，出票时需要去各个局数据库完成操作。

[mrchi]

@eason1874 可能我审题偏了。我主要是想吐槽并发的时候登录不上这个机制，在放票高峰的时候，即使买票不相关的操作，比如查看常用联系人，查看核验状态，修改个人信息也都做不成。

[est]

@bolide2005 更说明了「按区间段售票」就是产品经理式的拍脑袋思维。

[mrchi]

@zy8848 但是，丢弃到普通人使用 12306 网站都无法正常使用了（包括购票，查看个人信息等等），还合理吗？我甚至都没有办法抢候补

[kirch]

不能拆分下，一条线路一个系统。

[ajaxfunction]

12306 的难点不仅仅是向用户提供服务，
还的和 bypass，携程，飞猪 这些抢票软件做斗争，
普通用户 1 秒 5 个请求不得了了，而这些抢票软件的服务器 1 秒发出几千请求就和眨眼一样简单。

[sivacohan]

https://github.com/12306ng
好像大家都忘了这个了。

[fengci]

你们按座位算并发的吗？ 这东西不应该是每个区间都同时有一波人去抢票嘛？过节一趟车 抢票数是座位数的 100 倍都是正常的， 你要买 A 区间的票 别人也要买 B 区间的票啊

[pagepancn]

@woodensail 普通小电商水平，敢问楼主是何方神圣

[kimiler]

12306 和 马斯克的 SpaceX 哪个难？现在的中国互联网公司动不动市值上百亿，就做不好一个 12306 吗？还是缺少投入，净想着赚钱了。

[cooooler]

说并发小的有没有考虑它还要经受这么多抢票软件的不断接口请求

[deorth]

lmao，上新闻了
https://m.mydrivers.com/newsview/663914.html

[woodensail]

@pagepancn 又是一个不看前文的……

[Tezos]

手动艾特一下回形针

[askfilm]

@kimiler SpaceX 估值达到 333 亿美元, 另外我觉得 12306 已经做的很不错了, 打击各种黄牛及抢票软件是一条提升的方案

[itgoyo]

一群小菜逼都在装什么呢，你做出来试试？会个电商项目就能搞出淘宝？

[faemon]

楼上某些说不复杂的大佬去上，估计黄牛都没了，网站卡着黄牛可能想转行

[Jammar]

一辆车我可以买不同区间，我可以买不同车次，我可以买不同日期，再加上各类抢票软件的爬虫，2000 的并发不知道是怎么估出来的。抢票跟双十一秒杀完全是业务难度

[ily433664]

你们都跑题了，lz 说的是“业务逻辑”，按照实际情况来看，放票很多是固定区间的（全程有票，但是中间无票），就这种逻辑来说，的确算不上复杂

[Felldeadbird]

我认为是。因为涉及到国家铁路实际调度问题。这个需要自上而下人力去维护啊。不仅仅靠系统。

[leeton]

推到重做，外包给阿里，但是，没预算。只能勉强维持，升级。

[cutlove]

分不清反串与钓鱼的统一当智障处理

[yohn89]

@woodensail

荷载 1200 人，并不等于只有 1200 人乘车，不是所有人买票都是从起点买到终点的。

[alfchin]

@maskerTUI 除了开车前 2 小时，剩下的时间火车票都是预设区间留票的，根本不需要重算剩余区间票量

[luban]

cnBeta 收录这篇了

[love1017best]

@BlackSas #8 区间放票都是提前设定好的，有些不重要的区间在抢票高峰压根就不会放票

[yohn89]

@LuciferGo 他认为一个车次只有 1000 个座位，所有只有 1000 张票，并发不大。 今日最佳。

[hillwall]

12306 就是个普通小电商秒杀的水平
--------------
笑尿

[wwbfred]

这居然上新闻了...这帖子里谁是 cnbeta 的小编?你是不是又上班摸鱼...

[skyeycirno]

@kimiler #154 你这话说的，你不如说一个卖票系统和制造核武器谁难？我国核武器都有了还做不好一个卖票系统？

[cryring]

12306 逢年过节高峰期首发热门车次根本不放区间票，并没有区间拆分和排列组合的压力

[encro]

本身系统不算最难，
难度在于本来就没那么多票，
如果票足够，1 个小时就能抢完一年的票。

我说难度不大是因为可以拆解，比如订票：将不同起点终点城市的数据路由到不同的服务节点上，这样每个节点其实也就几千几万条数据，每天不到 1 分钟就能处理完。且这些节点一旦无票直接可以返回结果，没必要每次都查询。

当然，还有退票，换票，CDN，身份认证，反机器等，支付，短信发送等。

个人估算几百几千台服务器能搞定了，双十一可是几万台服务器啊。

系统卡？
我见过很多程序为了防止用户重复请求，都 sleep(random)的，
用户觉得卡，其实是为了减轻服务器负担，或者造成人多的错觉，故意的呢。


思考题：
为什么不能彻底屏蔽抢票程序呢？

[encro]

@xiasohan
@liaoyaoheng

证券交易也不算太难，阿里大佬有一个专门讲解证券交易 PostgreSQL 数据库设计的

https://github.com/digoal/blog/blob/master/201704/20170417_01.md

[encro]

技术有时候是需要出来背下锅的，
因为说实际情况（运力和需求的矛盾）你们又当作没听见。

理解了就明白为什么 12306 总是做不好。

其实，
个人觉得其实已经够好了，
很多非技术能解决问题。

[ziseyinzi]

不是理想实现，一定程度上算是降低了复杂度。比如票段信息不是实时更新的，线上线下库存也不实时同步。

[Ncanback]

@woodensail 我觉得你说并发不大 主要考虑的是一辆车首发放票的问题
例如 上海到南京 一趟列车 1w 个座位，放票 1w 张，你认为最终有效请求就是 1w。这是一个商品秒杀的逻辑

但问题在于 对于 12306，这 1w 的成功请求最终会产生数据的裂变。1w 个成功请求中 有 5000 个是上海到无锡的。那么就又会产生 5000 个无锡到南京的票可以被“抢”（请求）。这样一趟列车的可成功请求数就变为了 1w+5000 =1.5w 请求。
如果有 3000 人买的是 苏州到无锡的票。就会产生 3000 张上海到苏州 3000 张无锡到南京的票。加上之前的 总计是 1w+5000+3000+3000 = 2.1w 请求。

这个已经不是“普通小电商秒杀的水平”。涉及到了巨量复杂的余票计算和查询。

[melvin]

如果不复杂，12306 当初也不会找 IBM 了，IBM 却说搞不了，你们自己看着办吧

[WhiteSaber]

复杂度的话，金融业系统、航运业系统能排得上位

[shmilypeter]

复杂度大家说了很多了，还要有很多反爬，防止黄牛锁定库存等措施

[mritd]

虽然很多人在做正面教育，也有很多现实因素，但是我想说的是这个网站做的是真的垃圾；因为在非过节的时间段买票都出各种幺蛾子，还有时候神特么浏览器兼容，IE 打不开 chrome 好使，chrome 打不开 IE 好使；最后我想说一句 经费都去哪了？并不并发的加机器啊

[wangyzj]

先感谢刘志军
再感谢 12306.cn
最后感谢祖国

[justfortest]

哈哈，大佬在民间。

[bsidb]

铁科院在今年 BDTC 大会上公布的 2018 年中国铁路售票数量数据是：全年售票量超过 40 亿，日峰值售票量接近 1500 万，其中 12306 网站日峰值售票量超过 1200 万。

[Building]

实际上根本没这么复杂，一通瞎分析，敢情没 12306 的时候窗口还不能卖票了？

[ccppgo]

@leeton 铁道部有想外包给 IBM 和阿里, 都被拒绝了, 你找找老帖, 知乎都有, 新闻也有

[CruelMoon]

铁路的票务系统之外的系统恐怕就更复杂。。

[shiny]

上新闻了，这年头写个新闻真简单

[citydog]

我就喜欢前几个楼层的大神，说话又好听，猛一看还以为是在看今日头条呢！

[s1th]

楼上有些人真是无知者无畏

[neqhqrim]

原来楼主就是 cnbeta 的小编！

[lxk11153]

@sivacohan #153 这是啥？

[mytsing520]

有关 12306 系统的部分说明，知乎上几年前就有，搜搜就知道了。
12306 的复杂性在于，他只是铁路庞大的系统中的一个分支，牵一发而动全身。
我特别同意一个说法，这不是技术问题，而是需求问题。铁路不是云计算，想什么时候有车就什么时候有车，这种事情只能发生在梦里。
涉及公共利益方面，你做不到绝对公平，永远都会有人在骂你。相对于几年前，用另一种眼光看待，我们每年都能看到 12306 在不断进步不是吗？

[sivacohan]

@lxk11153 这个帖子里大家提出的问题和解决思路，几年前就有人提出过。而后，京东的一位技术副总提出 12306NG （下一代）。结果几年过去了，也不过是留了这样一个 GitHub。
一段时间内，12306NG 成了一个讽刺性的词汇。

[iccfish]

吓得我不敢说话。