光想想这并发量头就发麻,不像天猫双十一是短时间并发,12306 是一出票就双十一。
201
admin7785 2019-12-25 01:02:57 +08:00 via iPhone
一张车票很多区间,可以裂变出很多可能,要想做到利益最大化,这个逻辑我不敢想,也不会
|
202
QNLvw5fLfr7c 2019-12-25 01:07:10 +08:00 via Android 1
有理有据的论述,就算是犯了错误或是说明不充分,也是应该尊重的。
而上面冷嘲热讽的、不看后续讨论不假思索便就回复的、以及人身攻击的,占了一半楼层。 |
203
railgun 2019-12-25 01:54:48 +08:00
单论业务逻辑,我觉得最复杂的是 windows
|
204
tianshilei1992 2019-12-25 04:32:02 +08:00
@20150517 一列 K 打头的车几十站…
|
205
SlipStupig 2019-12-25 04:59:27 +08:00 3
大家要分几个层面看问题。
- 12306 这套东西大家都没考虑到它的历史包袱,最早的是时候为什么那么慢那么难用,是因为最早的 12306 是一个内部版本也就是以前在代售点那套系统,这套东西和铁路调度系统是强绑定的,当时 12306 是双系统制,外部下单相当于多了几个亿的火车票代售点,然后去提交,但是实际情况远远超过了当时铁总设计的预期,所以被骂的要死。 - 业务复杂度从最基本的票务类型开始算就很多类型:团体票、个人票、学生票,然后依次是座位类型和价格要进行动态计算价格,然后上架库存(觉得不以为然的自己可以尝试一下),然后就是噩梦的开始,用户一旦刷不出来票来就会拼命的刷新,本身就高负载遇到更大的压力,然后票务面临退改签这个过程要保证尽量不要出错,而且还要快速响应,确认作为后还要跟铁路系统对接,这个东西复杂度难以想象,当年只花了 3 个亿能做成已经相当不易。 |
206
ooh 2019-12-25 05:38:16 +08:00
好奇 12306 是怎么设计的?预先根据各个区间生成座位,然后客户端秒杀座位??区间越大优先级越高???因垂丝汀,翻了这么多楼为什么没看到哪个聪明鬼讨论这个🤣
|
207
dangyuluo 2019-12-25 06:16:58 +08:00
我昨天还喷了 12306😂知道不容易,但是也是很无奈
|
208
bullfrog 2019-12-25 07:40:21 +08:00 via iPhone
之前死去活来的,阿里派一个团队第二年就马上改善了,你说是简单还是复杂。。
|
209
aheadlead 2019-12-25 08:37:08 +08:00
|
210
aheadlead 2019-12-25 08:38:37 +08:00
|
211
zhihupron 2019-12-25 08:45:07 +08:00
12306 是导师让学生做的。大头导师赚了。
|
213
m939594960 2019-12-25 09:10:00 +08:00 1
虽然我水平烂,但是我还是要说如果给我那么些钱,我做出的东西绝对比 12306 牛逼,就 12306 那破 APP,那破网页(没改版之前点击操作都会卡住)
还有 12306 这么大的系统不是应该竞标的么?没那个本事就别接啊。 说个最浅显的东西: 1.冷热分离,那些火爆的线路就让它火爆吧,其他的线路是不是应该不受这些火爆线路的影响?个人中心是不是不应该受影响。 2.每日维护,请问一天维护 6 个小时,这 6 个小时要干啥? 3.那些说没超卖的请查查新闻好么? 4.那些说实时显示的先自己买个票好么? 其实我觉得可以说他复杂,但是做到这个程度大家都应该知道做这个系统的人什么水平 |
214
wangyifei6817 2019-12-25 09:17:04 +08:00
@m939594960 你是刚毕业还是是 2#的马甲啊?
随便查查这几年的资料都说不出这些话啊 兄弟 |
215
nicevar 2019-12-25 09:17:47 +08:00 via Android 1
@Building 无知,站着说话不腰疼,当年没有网络售票的时候你知道有多惨吗,北京西站一大堆人连续好几天通宵排队都买不上票,还下着雪,大家就站在雪地里挨冻
|
216
m939594960 2019-12-25 09:19:17 +08:00
@wangyifei6817 #214 嗯,如果有想反驳的请反驳,不想反驳就请别回复,你这样的回复并没有什么实际意义!
|
219
wulin 2019-12-25 09:51:38 +08:00
先不谈买票,卤煮可以试着设计一个余票查询,这个复杂度就很高了 /doge
|
220
openbsd 2019-12-25 09:53:20 +08:00
|
221
root8080 2019-12-25 09:56:32 +08:00
喜欢这样的帖 大家发表自己的真知灼见 (也许是错的但是哪有怎么样呢 看的很有味道啊! 大家和善一点嘛 说归说骂人的话就不要了
|
222
gamexg 2019-12-25 10:13:48 +08:00
@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 倍。 当然是及上需要考虑很多细节,例如拆分为了太多数据库维护上会比较麻烦。 上了缓存数据库,那么可能出现这次查询时用的缓存没票了, 但是实际其他缓存还是有票的。 不过实际看知乎上面参与开发的人员回答,目前的问题是实际票务数据是分别保存在不同铁路局,出票还需要去操作各个铁路局的数据库。这种情况下我觉得问题不是出在技术上面了。 |
223
338c 2019-12-25 10:15:43 +08:00
我猜 这个停机维护 是不是更新每天的热数据啊
猜每天要卖的票肯定有上限 假如用最快的存贮介质去存 比如 RAM 票有上限 RAM 就有上限 RAM 上限之后 程序生成一次或者插入 RAM 是不是也需要时间 限制与交互网络 和 其他的一些等等 插入的数据 是不是要需要效验一遍正确性 TB 级或者更大的 RAM 数据插入 效验 是不是需要更久的时间 ... .... |
224
iMusic 2019-12-25 10:18:00 +08:00
复杂确实很复杂,但不妨碍它做的就是烂
|
225
Myprincess 2019-12-25 10:22:26 +08:00
我觉得应该提高取消扣款率。车票 100,取消一次,扣 80 块。第二次购再取消,直接扣 100%。
重复订票手续费用。如果买广州到上海的,15 号买了票,你想再买 16 号广州到上海的直接加价 300%。 |
226
SurfaceView 2019-12-25 10:29:35 +08:00
|
227
smdbh 2019-12-25 10:52:12 +08:00
其实有很多技术或是规则上优化的地方。 那最后计算量就没那么大了。
在硬件水平有限的情况下,单纯的拼 crud,和写冒泡排序有那么点类似 当然忍不住透露下,以后大家都上 5g,抢票就不存在了, |
228
zxcslove 2019-12-25 11:00:49 +08:00
平衡问题:
高科技资本和大众之间 熟练玩家和普通群众之间 线上群体和线下群体之间 列车经过不同地域之间 ............ 完全只考虑线上售票,只从效率考量,哀鸿遍野,画美不看 |
229
youngster 2019-12-25 11:06:42 +08:00
@woodensail 你已经被 block,真的是哪里都想插一脚,哪里都想说两句?您真是不懂专业二字
|
230
woodensail 2019-12-25 11:09:14 +08:00
@youngster 心平气和的讨论技术问题不好吗?
|
231
ech0x 2019-12-25 11:11:44 +08:00
不是,日本的新干线系统远比这个复杂。
|
232
palexu 2019-12-25 11:13:17 +08:00 via Android
@ifxo 你以为阿里没去?阿里去了,没搞定好吧。说话之前先去查查资料,别想当然了。光 12306 那个内存数据库你就搞不定
|
233
palexu 2019-12-25 11:14:16 +08:00 via Android
@woodensail 承包我今日笑点
|
234
youngster 2019-12-25 11:15:54 +08:00
楼上那位说的对,不仅仅是网上售票的并发量,还要考虑各个站点,代售点票务系统的对接(全国多少个点不敢想象),光是同步的数据并发就很大了,而且考虑到站票、坐票、软硬座;站次、加仓、区间站,我觉得是复杂度前几的需求了。而且想想中国铁路的体量和国家牌面,这么多年不曾涨价的底气,我觉的他的票务系统一定不差钱也不差人;但是目前还是有很多问题和不理想的地方,足以说明复杂和困难仍然很多。
|
236
across 2019-12-25 11:22:43 +08:00
这算是年经贴了····
年年喊 12306 高峰崩溃不改,改了又能咋呢,票本来就不够,多开服务器给你登上去,无非多瞅下空票,能抢到票还是并发抢在前面的人。 想着不崩溃就好无非是不见棺材不掉泪。 |
237
woodensail 2019-12-25 11:25:53 +08:00
@palexu 哈,年末了嘛,多划划水。
|
238
Ncanback 2019-12-25 11:30:47 +08:00
@gamexg 如果是按照你所说的 那么每天晚上停止服务 应该就可以理解为 夜间各个铁路局自己的票池统计并汇总,制定第二天的出票数。同时在第二天产出“新”的票进行售卖。那这也太蠢了........
|
239
yaoye555 2019-12-25 11:39:47 +08:00
我可以这么理解么 这个贴明年这个时候拿出来依然可用, 事实证明 12306 改动的挺大的, 至少我俩年前写的爬虫脚本 现在已经不能用了[doge]
|
241
jun0205 2019-12-25 11:59:16 +08:00
12306 的问题不在 web 查询上面,复杂的是支撑整个 web 后面的架构。大部分人都不了解铁路售票系统是什么样的,在这谈 web 怎么样。
|
242
subpo 2019-12-25 12:23:07 +08:00
只是说业务逻辑的话还好吧...复杂是复杂的,还不至于最复杂
|
243
youweiks 2019-12-25 18:18:46 +08:00
|
244
lysS 2019-12-25 19:30:03 +08:00
@woodensail 别说卖票了,设计一个让火车在有限的轨道上同时运行,不撞车,还最高效的系统吧,别的不说。。
参考回形针怎么调度列车 https://www.bilibili.com/video/av42125169 |
245
Epsil0n9 2019-12-26 21:36:00 +08:00
@m939594960 #213 現在国内制度一向是利益为主,能力次之
|
246
Epsil0n9 2019-12-26 21:44:49 +08:00
@wangyifei6817 #214 每个人都有他的信息局限性,直接提供有效信息更有意义. 否则人之间就很难互相借鉴,也很难有说明力
|
247
elfish 2019-12-27 02:13:05 +08:00
比如 a-b-c10 座,初始 a-c,a-b,b-c 各最大 10 张,如果有人买 a-b,那 a-c 和 a-b 各减一张,这样成不,所有搭乘可能票数最大化,售出的时候把影响的线路一并减掉。另外,技术不行能不能搞成摇号啊,比起等半天卡死,抽空预约等摇号,摇中直接付费,没付费的票下一轮摇号,至少乘客买票轻松点。补充:一般不乘火车,刚问了下,好像买票的时候可能是涉及到多次列车的换乘,这样的话卖出一张票影响的路线就指数级增加了,难度大概在这吗?
|
248
linuxgoat 2019-12-27 23:01:47 +08:00
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 亿多人次,平均到每一天,大概是一千多万,还分布到全天不同时间段卖票,实际并发量没有特别高(没有达到上亿人同时抢票的程度) |
249
rizon 2019-12-31 17:08:31 +08:00
@woodensail #2 我觉得 2 楼说的有些道理吧,12306 系统的难点肯定是有的,但不至于问鼎巅峰吧。。。。
并发上我觉得问题确实不大啊,整体很多,但是具体到一个车次人数就没那么恐怖了吧? 再者,12306 的票都是分批次的定期放票,因此我们可以假设他们的票是固定分区间销售的,每天晚上维护的时候再重新根据销售情况去重新分配各个区间票,和同步各个服务器的数据,少了动态分配的问题,就再次降低了并发的各种疑难杂症。。。 换言之,12306 我觉得是从营销策略上来解决了分布式和并发的问题,是大家把 12306 想的太高级太神秘了,不自觉潜意识的认为是有黑科技支持,但其实反而是用了最简单粗暴的方式去解决问题 。。 难道是我想简单了???? |
250
i36lib 2019-12-31 18:06:05 +08:00
很多表面上看是技术问题的问题,事实上并不只是技术问题这么简单,各种流程、利益纠葛。
|
251
python 2020-01-01 01:02:13 +08:00 via Android
比 Google 复杂?
|
252
5G 2020-01-03 18:45:36 +08:00
你好,不是的,证券交易系统才是目前世界上业务逻辑最复杂的系统。
|
255
pythonee 2020-02-03 05:20:57 +08:00 via iPhone
应该不仅并发的问题吧
线路,排班,站点工作协调等等 12306 是个出票窗口,但铁路系统应该比较复杂 |
256
xinxijishuwyq 2021-01-15 21:11:23 +08:00
@leiuu 每个段这次最多售多少是提前定好的吧。。。全程有票区间无票不是很常见
|