或者在原理上该如何实现一个 12306 ，技术难点有哪些，欢迎大家讨论

感觉难度被夸大了。
用 bit 表示列车的站点区间，卖出一张票，就把对应的 bit 置 true ， 若对应区间都是 false 表示可乘。一趟列车不会超过 32 个停靠站，4 字节就够表示一趟列车上一个座位的售卖情况。全国 2 个月内的也就几个 G 内存就能装下。

余票查询操作全部是内存计算，没有 rpc ，没有锁甚至没有 cas 操作，可以做到单机很高的并发

www.zhihu.com/question/315887668 知乎有过讨论

可以，大概 2000 元预算就可以了。

找几个 985 计算机研究生就能搞定了,哪里需要什么复杂的技术和大量的资金投入啊

＃1 一个 bit 只能表示有或者无票吧，实际上是要表示票剩下数量有多少

这个话题 v2 之前对喷过好几页

系统本身应该就是调度算法和卖票相关的算法难. 以及更多的难处是要抗住全国节假日的短时间并发量、以及各黄牛 /脚本的外挂刷刷刷.

精英全在 v2🙏

一般的商城系统就可以，每个旅程段的车票无限多，根据订单现场造火车。

＃1 一个位图就解决啦?

“卖出一张票”，魔鬼藏在这里呢。

这楼里都是没有实际做过项目的产品在叨逼叨？

精英全在 v2🙏12306 就该来这边找外包，还搞什么全球招标。

有没有考虑过一个问题，比如一条线起点 a ，能到 b 和 c ，需要保证到 b 点的人至少百分之 60 能买到票，然后到 c 点的也要有百分之 60 （还包括 b 点上车的）能买到票，如果这样、还算简单吗？

再加上需要为线下保留百分之 10 的或者百分之五的票，为不方便网上买票的用户购买

v2 真牛，12306 没请你们真是失败

不能
别做梦了，业务复杂到你不可想象

我觉得这是很难的，座位算法是牵一发动全身那种，不只有直达，还会影响换乘的线路和时间，并且即时更新，加上超高并发，比双十一抢购还要难。

技术很简单，但不便宜哦，因为 v 友的时薪都很高。
按 12306 的工作量，最低 3000 块钱，并且，你得先付 1500 的定金。

原理不复杂，本质上还是商品售卖服务，就是商品级联的业务逻辑比较复杂，但是任何服务好用和能用背后的成本是两回事。

同理可以类推：搜索，从 like 语法到语义识别直接给答案，云泥之别。

12306 这种网站恶意和灰色流量可能比正常流量还多

不考虑恶意流量和对手攻击，很多事都好解决很多

12306 真正解决问题是自己开发排队系统，绝杀第三方

不能

看完我觉得 原铁道部没请 v2 的精英去开发 12306 是铁道部的损失🐶🐶🐶

只有 1＃ 2＃ 21＃ 有参与讨论

剩下全在冷嘲热讽

此贴可以下沉了, 因为可以预见接下来全是嘲讽.

挺简单的，我去年去某头部大厂面试，面试官就让我当场设计一个 12306 。[人麻了]

哈哈哈

技术难度没那么大，业务难度比较大。
什么实时计算复用就当扯淡就行了，铁路车票不是这么卖的。

v2 真牛，12306 没请你们真是失败
不考虑区间卖票最优解分配问题？不考虑经济效益问题？那么大的并发量不需要考虑锁？多个人买到同一张票？还有，你没注意到你周边座位基本都是和你目的地一样的吗？

铁路售票不是这么实时的哦，其实每趟车不同区间段的票，有多少票都是预定义好的。比如刚开票一般只放出来一部分起终点的票，中间站是不放票出来的，然后随着时间，之后慢慢放出来中间站的。

牛逼，都是高手，中科院没你们损失大了

System design 而论没有非常复杂
但是实际实现很难 很难

别一下子调到开发啊，需求调研，产品交互设计必不可少，先把这两个搞清楚了，再来谈开发。本末倒置了

为什么论坛都会变成阴阳怪气冷嘲热讽呢,贴吧 nga 知乎 v2 感觉都同质化了

遇到这这种帖子，不嘲讽怎么办？都这种情况了，难道还要好好说话？

＃33 因为阴阳怪气成了流行的表达，知乎有过一个讨论 www.zhihu.com/question/402147443

一瞬间甚至觉得是不是在钓鱼🤔

技术，钱资源不重要，首先你要扛得住几亿人骂你。

有钱谁管被骂多惨啊

我建议先不谈技术，而是先用人类自然语言来描述 12306 的需求。

大部分程序员都没有这么大并发的经验

先不谈技术实现，能把需求文档写清楚再说。
ABCDEF……Z 个站，卖出一张 AD 的票，AB 、BC 、CD 、AC 、BD 就要减少一张，这个数据库怎么改，前后端怎么同步，怎么压低超售概率，锁票逻辑，想想就让人头大。

主要难点还是流量大啊。那些个说卖票算法多复杂的，不如看看现在 12306 的算法，也不咋地啊。
今天抢火车票，又是传统的只有终点站有票其他没票。然后看心情隔几天发几张，这种算法我上我也行啊=。=

从实际体验上来说，卖票算法并不智能，也完全没做到什么能让 60%的人买上票这么神。

这才是符合商业利益的算法啊，补票的时候就直接不装了，谁买全程谁就优先排队

搞得我以为 12306 不是程序员开发的。

12306 多少也是个千人起步的系统，能 hold 住技术这一块的最最起码是个大厂的 VP ，这个是 CTO 岗位。

扪心问一下自己。。。让你当 CTO ，你有这个能力不。

难度不是在上亿级别的并发吗？

＃45 对的，所以我现在就很绝望，ABCDEFGHIJK 这几个车站，我这次是抢 A 到 I 的，硬是一到发售就没了，我怀疑压根没放票，而 A 到 K 的，我现在看还是“有”。
我看了到 J 的也是一张都没有。合着只有起始到终点站的呗，然后候补也不知道啥时候是个头，影响后续规划。
等到候补到了没几天了，然后其他日期的票要退，又是一笔手续费。12306 赚麻了。

是的，上来就技术的一看就离谱，真正主导做过系统的哪有这么搞的

你们都太负责任了，想得太复杂。

实际上 12306 是玩忽职守的，售票是随意决定的。

将所有可能的票按类型提前分配好，就像数据库分区一样，分到具体节点，每个节点负责一小部分票。

售票的时候，负载均衡将用户分配到售票节点。
分给你的节点卖光了，就跟你说没票。即便全局来看其他的节点还有票。

平常的时候一列车就一个售票节点，余票是可靠的，就剩一张票你也能买到，春运的时候一列车一排节点，
余票是不可靠的，你买到票的概率是随机的。

就第一眼的需求
感觉自己写不了，好复杂，可能我的经验还不够

＃42 补充一个还要票务分配 线上线下每日比例放票 海量的线下窗口各种客户端都在疯狂出票

铁路上的票是预分配好的

＃5
＃1 楼说的是区间是不是有票，比如 A11 这个座位的值是 00111100 ，就表示 A11 座位从第 3 站到第 6 站这 4 站的票已经有人占用了。余票数量跟这个没关系。

这么多年的购票经历来看； 3000 块，只参与买票，不能参与卖票

抢得是位置，而不是票

我同学大学本科毕设就是抢票工具 接口确实免费，可以参考下 www.bypass.cn/

我觉得你说的有道理啊。从外面看似系统遵守业务规则，其实从内部看做了很多妥协。

先说一点, 各个站的票数是写死的, 并不是动态算的.

我回家是 A -> B -> C 的中间站 B, A -> B 每次应该是只有 2 张票, 我买不到, 都是直接买 A -> C 的.

你要能满足那么高并发，不是件简单的事

别说技术了,需求能完全整清楚并且表述出来形成需求文档都没几个

我记得 12306 刚出来的时候，经常崩溃，也有一群程序员，不知天高地厚的想要挑战，觉得开发 12306 的都是沙比，殊不知，业务复杂度高得很

我记得之前看到的，12306 的票不是动态分配的，举例：
A B C 三个站，1000 张票
A-C 800 张
B-C 200 张
第一天开放其中一半的售票，过几天再开放 30%，过几天再把剩下的开放

我记得大概是这个逻辑，如果不对请指正

v2 高手就是多啊🙏🏻

不谈抢购什么, 你先把动态分配车票逻辑搞定.

我觉得＃1 说的很对，难度被夸大了。

直到现在，12306 的余票数量还是像量子力学一样，一会儿显示有票一会儿又突然消失一会儿又出现那个数字，然后点进去买票，就显示出票失败。
所以，同步加锁并没有想象的那么严酷。

另外，铁路看起来那么多条挺吓人，但是各个线路是没有关系的啊，所以考虑难度的话，只考虑 1 条线路就好了，1 条还觉得很难吗？

内存方面＃1 楼也论证了，几个 G 的内存就足够了，1 台机器不行的话，就多加几台，内存纠错，大带宽同步传输。挺快的。:doge

为什么要一个人开发。。。

我觉得你说的很有到里，讨论到现在，所有人都是把业务简化到并发的库存管理。对于 12306 整体业务的描述，需要满足的性能指标，很好见到人讨论的。只能说，大多数人讨论的都是理论上是否可行，或者在讨论的是能不能完成一个 demo

太简单了，不是随便画个原型，Ai 自动帮你实现了所有功能吗？

一个 iframe 标签解决

可以, 但是你性能指标不行啊.

你说的这些难度不在于研发

我同意你的说法，毕竟是卖方市场，只要能解决大并发不崩溃，剩下的可以慢慢售卖，基本不会让人感觉到体验差，甚至体验会更好，想想最后三天抢到票的感觉，晚上睡觉都会笑。

牛啊，夏虫不可语冰

稍微想一想 业务复杂度就很高了……

纯线上的话相信大多没啥问题，难的是和线上与线下相统一

＃55 如果这样就更离谱了，一趟列车的座位 20516=1600 个座位左右，假设每个座位都是 32 个停靠站，6.4K 。车次数据网上没查到比较具体的，大概是千次？算 5000 车次 大概是 32M 内存一天。咋一看确实可以，但是还要考虑分部署冗余等问题

是的。很多人都理解错卖票业务了，并不存在你买了 A-D 的票就影响他买 A-B 的票的情况

大神🙏🏻

不存在你买 A-D 影响 A-C 的情况，没有 12306 的还得线下抢票的时候就不是这样，不是实时的，你想复杂了

你看到的已经是完成业务优化的 12306 了，分时段，分车次，分量放票，自己带补票功能

一开始全放出来全民开抢，而且没疫情的时候，扛住了才是奇迹

＃78
所以啊，1 天才对应 32M 内存呢。不同天的数据是可以分布式的，1 台机器只处理 1 天的订票工作不就可以减轻负担了吗？

按照前楼的说法，买了 A-D 的票不影响买 A-B 的票，内存还可以减少。20 个站，两两形成 200 个起点-终点对，每个起点-终点对维护一个剩余票数，2*200=400 字节就够了。

其实把这个问题简化，很多都是可以并发的，而且是完全的并发，不需要同步。

• 5000 个车次，分给 5000 台机器，每个机器处理 1 个车次的订票操作，互不干扰
• 20 天内的订票，分给 20 台机器，每个机器只处理某 1 天的订票
• 20 个站，两两之间形成 200 个起点-终点对，彼此之间的剩余票数也是独立的(按照前楼说法)，分给 200 台机器去各自处理。

按照每天发送 1000 万次旅客的高峰，5000*200 台机器并发，每台机器只需要响应 10 次订票请求就可以了。

看别人做都很容易，自己做起来真叫难。难度在于，很多事你都无法用精确的语言描述出来

缺 3 亿人民币雇人开发

一个人的话 弄个抢不到票的应该问题不大

乘票售卖系统难度不大，难度大的是铁路调度系统

难在业务，所谓高并发层面也就那样。

PS：最近上去看，历史订单只能查看 30 天的。

水平有限，给钱开发个省内公交🚌系统还可以，火车搞不来

我记得有几个开发 12306 的人写的帖子，写的挺中肯的。

求链接

一趟车每个站票数是不一样的，而且要知道余票的数量，一张票可能还属于多个区间可以重复买卖等问题，还有等等其他一系列问题，你考虑得场景太少了

讨论这个问题可以先看懂需求， 中国铁路是按什么方式分配车票的？ www.zhihu.com/question/36029493

挺难的，自己写可能写个抢票脚本都写不明白

感觉难点不在设计算法有多难，而是超高的并发和超大的了流量。

很久远了。刚刚去搜索了一番书签，没有找到了。

前员工答一波
Q: 技术难点有哪些?
A: 1. 全局性事务

2. 流量压力
3. 前置检查
4. 车票区段售卖

1. 全局性事务
   现阶段最难的是全局性事务, 因为保密原因, 不能说太多, 一句话概述就是整个系统存在事务问题导致的性能低下
2. 流量压力
   众所周知
3. 前置检查
   你买一张票的前置检查多到你无法想象, 目前的做法是线性检查, 提过并行检查的意见, 被否了
4. 车票区段售卖
   其实车票不是 12306 卖的, 实际卖票的是 18 个铁路局, 12306 只是一个售卖平台.
   12306 只是拿到票然后根据用户提交的席位来分配这些票.

总体来说 12306 目前的复杂性都是因为技术债务导致的.
如果抛弃全部包袱, 重新开发需要 200 人的团队开发大概 3 年左右.

＃64
现在除了重大节日 其他时间放票都是 98%互联网放票

光说不做的话，那 12306 这事，我一个人一星期就搞定了，洒洒水而已。

按一般政务系统的研发费用配置情况，实际研发费用我觉得不会超过 1000 W