这是一个创建于 675 天前的主题，其中的信息可能已经有所发展或是发生改变。
或者在原理上该如何实现一个 12306 ，技术难点有哪些，欢迎大家讨论
 |
1
sam384sp4 2023-01-05 11:45:29 +08:00  3
感觉难度被夸大了。
用 bit 表示列车的站点区间，卖出一张票，就把对应的 bit 置 true ， 若对应区间都是 false 表示可乘。一趟列车不会超过 32 个停靠站，4 字节就够表示一趟列车上一个座位的售卖情况。全国 2 个月内的也就几个 G 内存就能装下。 余票查询操作全部是内存计算，没有 rpc ，没有锁甚至没有 cas 操作，可以做到单机很高的并发 |
 |
2
xiangchen2011 2023-01-05 11:49:50 +08:00
|
 |
3
loading 2023-01-05 11:50:40 +08:00 4
可以，大概 2000 元预算就可以了。
|
 |
4
imzcg2 2023-01-05 11:54:36 +08:00 2
找几个 985 计算机研究生就能搞定了,哪里需要什么复杂的技术和大量的资金投入啊
|
 |
6
xtreme1 2023-01-05 11:57:44 +08:00
这个话题 v2 之前对喷过好几页
|
 |
7
wu67 2023-01-05 12:01:57 +08:00 1
系统本身应该就是调度算法和卖票相关的算法难. 以及更多的难处是要抗住全国节假日的短时间并发量、以及各黄牛 /脚本的外挂刷刷刷.
|
 |
8
dqzcwxb 2023-01-05 12:02:14 +08:00 42
精英全在 v2🙏
|
 |
9
hfl1995 2023-01-05 12:05:05 +08:00 52
一般的商城系统就可以，每个旅程段的车票无限多，根据订单现场造火车。
|
 |
11
darkengine 2023-01-05 12:10:13 +08:00
@sam384sp4 “卖出一张票”，魔鬼藏在这里呢。
|
 |
12
churchill 2023-01-05 12:10:43 +08:00
这楼里都是没有实际做过项目的产品在叨逼叨？
|
 |
13
abersheeran 2023-01-05 12:10:54 +08:00 3
精英全在 v2🙏12306 就该来这边找外包，还搞什么全球招标。
|
 |
14
kekxv 2023-01-05 12:12:52 +08:00 via iPhone
有没有考虑过一个问题，比如一条线起点 a ，能到 b 和 c ，需要保证到 b 点的人至少百分之 60 能买到票，然后到 c 点的也要有百分之 60 （还包括 b 点上车的）能买到票，如果这样、还算简单吗？
|
|
15
kekxv 2023-01-05 12:13:58 +08:00 via iPhone
再加上需要为线下保留百分之 10 的或者百分之五的票，为不方便网上买票的用户购买
|
 |
16
sparkpark 2023-01-05 12:14:58 +08:00 21
v2 真牛，12306 没请你们真是失败
|
 |
17
liprais 2023-01-05 12:16:10 +08:00 via iPhone 1
不能
别做梦了，业务复杂到你不可想象 |
 |
18
wonderfulcxm 2023-01-05 12:16:42 +08:00 via iPhone 1
我觉得这是很难的，座位算法是牵一发动全身那种，不只有直达，还会影响换乘的线路和时间，并且即时更新，加上超高并发，比双十一抢购还要难。
|
 |
19
ttgo 2023-01-05 12:18:43 +08:00 1
技术很简单，但不便宜哦，因为 v 友的时薪都很高。
按 12306 的工作量，最低 3000 块钱，并且，你得先付 1500 的定金。 |
 |
20
mrgeneral 2023-01-05 12:21:08 +08:00
原理不复杂，本质上还是商品售卖服务，就是商品级联的业务逻辑比较复杂，但是任何服务好用和能用背后的成本是两回事。
同理可以类推：搜索，从 like 语法到语义识别直接给答案，云泥之别。 |
 |
21
murmur 2023-01-05 12:22:36 +08:00
|
 |
22
superchijinpeng 2023-01-05 12:29:58 +08:00 1
不能
|
 |
23
bruce0 2023-01-05 12:31:08 +08:00
看完我觉得 原铁道部没请 v2 的精英去开发 12306 是铁道部的损失🐶🐶🐶
|
 |
24
me221 2023-01-05 12:35:26 +08:00 14
只有 1# 2# 21# 有参与讨论
剩下全在冷嘲热讽 |
|
25
me221 2023-01-05 12:36:16 +08:00
此贴可以下沉了, 因为可以预见接下来全是嘲讽.
|
 |
26
dlmy 2023-01-05 12:38:15 +08:00 1
挺简单的，我去年去某头部大厂面试，面试官就让我当场设计一个 12306 。[人麻了]
|
 |
28
AyaseEri 2023-01-05 12:50:28 +08:00
技术难度没那么大，业务难度比较大。
什么实时计算复用就当扯淡就行了，铁路车票不是这么卖的。 |
 |
29
xtinput 2023-01-05 12:55:11 +08:00
v2 真牛，12306 没请你们真是失败
@sam384sp4 不考虑区间卖票最优解分配问题？不考虑经济效益问题？那么大的并发量不需要考虑锁？多个人买到同一张票？还有，你没注意到你周边座位基本都是和你目的地一样的吗？ |
 |
30
maemual 2023-01-05 12:57:01 +08:00
铁路售票不是这么实时的哦，其实每趟车不同区间段的票，有多少票都是预定义好的。比如刚开票一般只放出来一部分起终点的票，中间站是不放票出来的，然后随着时间，之后慢慢放出来中间站的。
|
 |
31
isno 2023-01-05 13:00:48 +08:00
牛逼，都是高手，中科院没你们损失大了
|
 |
32
SeaTac 2023-01-05 13:02:52 +08:00 via iPhone
System design 而论没有非常复杂
但是实际实现很难 很难 |
 |
33
xmh51 2023-01-05 13:05:02 +08:00 2
别一下子调到开发啊，需求调研，产品交互设计必不可少，先把这两个搞清楚了，再来谈开发。本末倒置了
|
 |
34
Hancock 2023-01-05 13:07:10 +08:00 5
为什么论坛都会变成阴阳怪气冷嘲热讽呢,贴吧 nga 知乎 v2 感觉都同质化了
|
 |
35
masterclock 2023-01-05 13:12:01 +08:00 4
@Hancock 遇到这这种帖子，不嘲讽怎么办？都这种情况了，难道还要好好说话？
|
 |
36
cskeleton 2023-01-05 13:12:39 +08:00
@Hancock #33 因为阴阳怪气成了流行的表达，知乎有过一个讨论 https://www.zhihu.com/question/402147443
|
 |
38
vhus 2023-01-05 13:13:49 +08:00
技术，钱资源不重要，首先你要扛得住几亿人骂你。
|
 |
39
likunyan 2023-01-05 13:16:26 +08:00
有钱谁管被骂多惨啊
|
 |
40
DOLLOR 2023-01-05 13:17:20 +08:00 6
我建议先不谈技术，而是先用人类自然语言来描述 12306 的需求。
|
 |
41
akira 2023-01-05 13:26:12 +08:00
大部分程序员都没有这么大并发的经验
|
 |
42
cnkuner 2023-01-05 13:38:10 +08:00 4
先不谈技术实现，能把需求文档写清楚再说。
ABCDEF……Z 个站，卖出一张 AD 的票，AB 、BC 、CD 、AC 、BD 就要减少一张，这个数据库怎么改，前后端怎么同步，怎么压低超售概率，锁票逻辑，想想就让人头大。 |
 |
43
xloger 2023-01-05 13:44:06 +08:00
主要难点还是流量大啊。那些个说卖票算法多复杂的，不如看看现在 12306 的算法，也不咋地啊。
今天抢火车票，又是传统的只有终点站有票其他没票。然后看心情隔几天发几张，这种算法我上我也行啊=。= |
 |
44
yaphets666 2023-01-05 13:44:45 +08:00
从实际体验上来说，卖票算法并不智能，也完全没做到什么能让 60%的人买上票这么神。
|
 |
46
dobelee 2023-01-05 13:46:53 +08:00
搞得我以为 12306 不是程序员开发的。
|
 |
47
glfpes 2023-01-05 13:47:32 +08:00
12306 多少也是个千人起步的系统，能 hold 住技术这一块的最最起码是个大厂的 VP ，这个是 CTO 岗位。
扪心问一下自己。。。让你当 CTO ，你有这个能力不。 |
 |
48
fengye0509 2023-01-05 13:51:20 +08:00
难度不是在上亿级别的并发吗？
|
|
49
xloger 2023-01-05 13:53:11 +08:00
@murmur #45 对的，所以我现在就很绝望，ABCDEFGHIJK 这几个车站，我这次是抢 A 到 I 的，硬是一到发售就没了，我怀疑压根没放票，而 A 到 K 的，我现在看还是“有”。
我看了到 J 的也是一张都没有。合着只有起始到终点站的呗，然后候补也不知道啥时候是个头，影响后续规划。 等到候补到了没几天了，然后其他日期的票要退，又是一笔手续费。12306 赚麻了。 |
 |
51
nomagick 2023-01-05 13:59:48 +08:00 2
你们都太负责任了，想得太复杂。
实际上 12306 是玩忽职守的，售票是随意决定的。 将所有可能的票按类型提前分配好，就像数据库分区一样，分到具体节点，每个节点负责一小部分票。 售票的时候，负载均衡将用户分配到售票节点。 分给你的节点卖光了，就跟你说没票。即便全局来看其他的节点还有票。 平常的时候一列车就一个售票节点，余票是可靠的，就剩一张票你也能买到，春运的时候一列车一排节点， 余票是不可靠的，你买到票的概率是随机的。 |
 |
52
fuwu1245 2023-01-05 14:03:01 +08:00
就第一眼的需求
感觉自己写不了，好复杂，可能我的经验还不够 |
 |
54
raycool 2023-01-05 14:04:11 +08:00
铁路上的票是预分配好的
|
 |
55
sillydaddy 2023-01-05 14:04:53 +08:00
@picone #5
#1 楼说的是区间是不是有票，比如 A11 这个座位的值是 00111100 ，就表示 A11 座位从第 3 站到第 6 站这 4 站的票已经有人占用了。余票数量跟这个没关系。 |
 |
56
mozhizhu 2023-01-05 14:05:37 +08:00
这么多年的购票经历来看； 3000 块，只参与买票，不能参与卖票
|
 |
57
yogogo 2023-01-05 14:07:11 +08:00 1
抢得是位置，而不是票
|
 |
58
monkeyblog 2023-01-05 14:11:20 +08:00
我同学大学本科毕设就是抢票工具 接口确实免费，可以参考下 https://www.bypass.cn/
|
 |
60
Jooooooooo 2023-01-05 14:18:55 +08:00
先说一点, 各个站的票数是写死的, 并不是动态算的.
我回家是 A -> B -> C 的中间站 B, A -> B 每次应该是只有 2 张票, 我买不到, 都是直接买 A -> C 的. |
 |
61
howfree 2023-01-05 14:20:35 +08:00
你要能满足那么高并发，不是件简单的事
|
 |
62
BrookO 2023-01-05 14:25:57 +08:00 4
别说技术了,需求能完全整清楚并且表述出来形成需求文档都没几个
|
 |
63
fuchish112 2023-01-05 14:26:20 +08:00
我记得 12306 刚出来的时候，经常崩溃，也有一群程序员，不知天高地厚的想要挑战，觉得开发 12306 的都是沙比，殊不知，业务复杂度高得很
|
 |
64
0bSer7er 2023-01-05 14:31:06 +08:00
我记得之前看到的，12306 的票不是动态分配的，举例：
A B C 三个站，1000 张票 A-C 800 张 B-C 200 张 第一天开放其中一半的售票，过几天再开放 30%，过几天再把剩下的开放 我记得大概是这个逻辑，如果不对请指正 |
 |
65
xrr2016 2023-01-05 14:33:11 +08:00
v2 高手就是多啊🙏🏻
|
 |
66
justfindu 2023-01-05 14:33:32 +08:00
不谈抢购什么, 你先把动态分配车票逻辑搞定.
|
|
67
sillydaddy 2023-01-05 14:39:11 +08:00 1
我觉得#1 说的很对，难度被夸大了。
直到现在，12306 的余票数量还是像量子力学一样，一会儿显示有票一会儿又突然消失一会儿又出现那个数字，然后点进去买票，就显示出票失败。 所以，同步加锁并没有想象的那么严酷。 另外，铁路看起来那么多条挺吓人，但是各个线路是没有关系的啊，所以考虑难度的话，只考虑 1 条线路就好了，1 条还觉得很难吗？ 内存方面#1 楼也论证了，几个 G 的内存就足够了，1 台机器不行的话，就多加几台，内存纠错，大带宽同步传输。挺快的。:doge |
 |
68
polobug 2023-01-05 14:39:17 +08:00
为什么要一个人开发。。。
|
 |
69
zmqiang 2023-01-05 14:44:18 +08:00
@BrookO 我觉得你说的很有到里，讨论到现在，所有人都是把业务简化到并发的库存管理。对于 12306 整体业务的描述，需要满足的性能指标，很好见到人讨论的。只能说，大多数人讨论的都是理论上是否可行，或者在讨论的是能不能完成一个 demo
|
 |
70
Terry05 2023-01-05 14:48:21 +08:00
太简单了，不是随便画个原型，Ai 自动帮你实现了所有功能吗？
|
 |
71
1t1y1ILnW0x5nt47 2023-01-05 14:51:38 +08:00
一个 iframe 标签解决
|
 |
72
lslqtz 2023-01-05 14:52:30 +08:00
可以, 但是你性能指标不行啊.
|
 |
74
tisswb 2023-01-05 15:06:48 +08:00
@nomagick 我同意你的说法，毕竟是卖方市场，只要能解决大并发不崩溃，剩下的可以慢慢售卖，基本不会让人感觉到体验差，甚至体验会更好，想想最后三天抢到票的感觉，晚上睡觉都会笑。
|
 |
75
jackbrother 2023-01-05 15:07:52 +08:00
@sam384sp4 牛啊，夏虫不可语冰
|
 |
76
ZField 2023-01-05 15:08:09 +08:00
稍微想一想 业务复杂度就很高了……
|
 |
77
Huelse 2023-01-05 15:08:25 +08:00
纯线上的话相信大多没啥问题，难的是和线上与线下相统一
|
 |
78
picone 2023-01-05 15:11:54 +08:00
@sillydaddy #55 如果这样就更离谱了，一趟列车的座位 20*5*16=1600 个座位左右，假设每个座位都是 32 个停靠站，6.4K 。车次数据网上没查到比较具体的，大概是千次？算 5000 车次 大概是 32M 内存一天。咋一看确实可以，但是还要考虑分部署冗余等问题
|
 |
79
codespots 2023-01-05 15:12:48 +08:00
|
|
81
codespots 2023-01-05 15:14:20 +08:00
@cnkuner 不存在你买 A-D 影响 A-C 的情况，没有 12306 的还得线下抢票的时候就不是这样，不是实时的，你想复杂了
|
|
82
murmur 2023-01-05 15:26:50 +08:00
|
|
83
sillydaddy 2023-01-05 15:40:55 +08:00 1
@picone #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 次订票请求就可以了。 |
 |
84
jiansongy 2023-01-05 15:42:59 +08:00
看别人做都很容易，自己做起来真叫难。难度在于，很多事你都无法用精确的语言描述出来
|
 |
85
YouTing 2023-01-05 15:46:15 +08:00
缺 3 亿人民币雇人开发
|
 |
86
UpMo 2023-01-05 15:47:19 +08:00
一个人的话 弄个抢不到票的应该问题不大
|
 |
87
OoGKoO 2023-01-05 15:48:02 +08:00
乘票售卖系统难度不大，难度大的是铁路调度系统
|
 |
88
wolfie 2023-01-05 15:54:27 +08:00
难在业务，所谓高并发层面也就那样。
PS：最近上去看，历史订单只能查看 30 天的。 |
 |
89
vevlins 2023-01-05 16:01:49 +08:00
水平有限，给钱开发个省内公交🚌系统还可以，火车搞不来
|
 |
90
zhanlanhuizhang 2023-01-05 16:05:43 +08:00
我记得有几个开发 12306 的人写的帖子，写的挺中肯的。
|
 |
91
feller 2023-01-05 16:06:30 +08:00
@zhanlanhuizhang 求链接
|
 |
92
Befehishaber 2023-01-05 16:07:16 +08:00
@sam384sp4 一趟车每个站票数是不一样的，而且要知道余票的数量，一张票可能还属于多个区间可以重复买卖等问题，还有等等其他一系列问题，你考虑得场景太少了
|
 |
93
GiantHard 2023-01-05 16:13:29 +08:00
讨论这个问题可以先看懂需求， 中国铁路是按什么方式分配车票的？ https://www.zhihu.com/question/36029493
|
 |
94
zw1one 2023-01-05 16:16:34 +08:00
挺难的，自己写可能写个抢票脚本都写不明白
|
 |
95
mosliu 2023-01-05 16:24:08 +08:00
感觉难点不在设计算法有多难，而是超高的并发和超大的了流量。
|
|
96
zhanlanhuizhang 2023-01-05 16:27:22 +08:00
@feller 很久远了。刚刚去搜索了一番书签，没有找到了。
|
 |
97
Jinnyu 2023-01-05 16:27:28 +08:00 41
前员工答一波
Q: 技术难点有哪些? A: 1. 全局性事务 2. 流量压力 3. 前置检查 4. 车票区段售卖 1. 全局性事务 现阶段最难的是全局性事务, 因为保密原因, 不能说太多, 一句话概述就是整个系统存在事务问题导致的性能低下 2. 流量压力 众所周知 3. 前置检查 你买一张票的前置检查多到你无法想象, 目前的做法是线性检查, 提过并行检查的意见, 被否了 4. 车票区段售卖 其实车票不是 12306 卖的, 实际卖票的是 18 个铁路局, 12306 只是一个售卖平台. 12306 只是拿到票然后根据用户提交的席位来分配这些票. 总体来说 12306 目前的复杂性都是因为技术债务导致的. 如果抛弃全部包袱, 重新开发需要 200 人的团队开发大概 3 年左右. |
 |
99
fisherwei 2023-01-05 16:31:37 +08:00
光说不做的话，那 12306 这事，我一个人一星期就搞定了，洒洒水而已。
|
 |
100
dcsite 2023-01-05 16:33:25 +08:00
按一般政务系统的研发费用配置情况，实际研发费用我觉得不会超过 1000 W
|
Select Language