V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX 提问指南
justrand
V2EX  ›  问与答

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

  •  7
     
  •   justrand · 2019-12-24 11:20:14 +08:00 · 27309 次点击
    这是一个创建于 1071 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

    第 1 条附言  ·  2019-12-24 12:25:49 +08:00
    稍微理了下思路:
    火车票是一个基于库存又需要 100%正确(也看到过报道一票超卖的现象我不知道是不是真的)的销售,同时还有神奇的乘车区间合并拆分以及车票的排列组合,光是想想就很困难呀<br>
    256 条回复    2021-01-15 21:11:23 +08:00
    1  2  3  
    mrchi
        1
    mrchi  
       2019-12-24 11:37:44 +08:00   ❤️ 1
    我觉得并不是。

    12306 一到整点的时候验证码和手机扫码的二维码都刷不出来。都是 post 请求,竟然直接 302 去 get error.html 页面,Nginx 就能做,都进不到业务系统哪来的并发呢?

    即使你侥幸提前登录上了,也能莫名奇妙的把你踢出来让你重新登录,但高峰一过,你就发现自己还是登录着的,惊喜不?
    woodensail
        2
    woodensail  
       2019-12-24 11:46:37 +08:00
    不是,12306 这个也就是个普通小电商秒杀的水平。很简单的一点,12306 的业务是非常容易分割到分布式服务器上的。
    最核心的交易流程甚至可以分割到一台服务器只管一个车次。一个车次总共才多少车牌,能有多大并发。
    eason1874
        3
    eason1874  
       2019-12-24 11:50:17 +08:00   ❤️ 5
    @mrchi #1 并发太高,后端处理不过来,高峰期前端把一部分请求扔掉了,没到后端所以就没有返回正确状态,高峰期过了,全部请求都能通过,就流畅。

    @woodensail #2 你真的没见识,你随便去抓个刷票软件的包你就知道并发多大了,我敢说 12306 春运期间至少有 10 天时间超过双 11 天猫淘宝高峰。
    zy8848
        4
    zy8848  
       2019-12-24 11:53:53 +08:00   ❤️ 4
    @mrchi 秒杀类应用丢弃一些请求不是常识么?被你窥探到常识后就突然就没技术含量了?
    woodensail
        5
    woodensail  
       2019-12-24 11:54:31 +08:00   ❤️ 5
    说别人没见识的时候自己查查数据吧。
    天猫公布 2019 年双十一时每秒成交量最高达到 55 万单。
    12306 只有 2015 的数据,峰值时每秒 1000 单,考虑到列车运力有限,现在估计也不会超过每秒 2000 单。
    这都是官方公布数据,差距明明白白的摆着
    helionzzz
        6
    helionzzz  
       2019-12-24 11:56:07 +08:00   ❤️ 50
    笑看楼上的一些大佬,真是高手在民间,我上我也行~
    woodensail
        7
    woodensail  
       2019-12-24 11:58:18 +08:00
    说白了,大促考验在哪里,一个是单节点抗压能力,这个压力主要看同一个商品有多少少人抢,12306 同时抢同一个车次一般不会超过 1 万人,而电商秒杀 1 万人是小意思。
    第二点则更重要,就是整个系统的抗压能力,考验各子系统的性能,以及降级策略,还有整个网络价格,这个指标基本上就是看秒成交量,而上面说了,官方数据显示,天猫秒成交量峰值超过 12306 百倍。
    BlackSas
        8
    BlackSas  
       2019-12-24 11:58:27 +08:00
    12306 跟淘宝可不一样。12306 同一班车这么多站,每个人起始站跟终点站都不同,这么多人一起抢同一班车。我觉得不容易。
    icyalala
        9
    icyalala  
       2019-12-24 12:00:44 +08:00
    并发请求很高,这个没的说。
    不过单就 "复杂度" 来说,应该到不了 "最复杂" 的那种程度,我更倾向于认为这属于特定问题。
    woodensail
        10
    woodensail  
       2019-12-24 12:04:12 +08:00
    @BlackSas 其实不难,因为一个车次视为一个整体,也才 1000 张票,压力不大。
    而且由于以前人工售票的历史原因,12306 习惯于把票分拆后分配给各个区间,各个区间只能卖自己区间的票。一个区间的卖完了,哪怕其他的票一张都卖不出去,你也没法借过来用,只能等下一次分配。
    passerbytiny
        11
    passerbytiny  
       2019-12-24 12:07:19 +08:00   ❤️ 11
    @woodensail #5 电商成交本质上就是 CRUD, 而火车票是票务系统,而且是动态排座的票务系统,所以:请不要搞笑。
    NerverLibis
        12
    NerverLibis  
       2019-12-24 12:09:04 +08:00 via iPhone   ❤️ 3
    民科又来忽悠人了 快跑
    findmyself
        13
    findmyself  
       2019-12-24 12:12:29 +08:00
    @passerbytiny 真是笑 skr 人了 哈哈哈
    optional
        14
    optional  
       2019-12-24 12:12:36 +08:00
    12306 虽然请求了高,但是业务是天然可以 sharding 的,最后具体到一班车的并发度并不高。
    jun0205
        15
    jun0205  
       2019-12-24 12:13:29 +08:00
    没做过票务系统的就不要说业务简单了。
    kop1989
        16
    kop1989  
       2019-12-24 12:18:18 +08:00   ❤️ 1
    单说面向用户这端其实并不复杂,是有一些技术难题,比如高并发。

    但其实出票这整个流程是极其复杂的。也就是说其复杂是复杂在票务上,并不复杂在抢购上。
    eason1874
        17
    eason1874  
       2019-12-24 12:18:46 +08:00   ❤️ 18
    @woodensail #5 笑死人,成交量跟并发是一回事吗?

    12306 高峰期单日 PV 能超过 1500 亿次,平均每秒超过 173 万次,你告诉我有哪个小电商秒杀能承受这个量级?别说余票这种复杂查询,就是你说的秒杀场景,全国能扛得起这个请求数的网站也屈指可数。
    bequt
        18
    bequt  
       2019-12-24 12:24:15 +08:00   ❤️ 1
    这个感觉不是单独的秒杀吧, 秒杀都知道有黑号概念, 黑号直接没有资格参与秒杀
    12306 可是没有设置黑号的啵
    Raymon111111
        19
    Raymon111111  
       2019-12-24 12:27:38 +08:00   ❤️ 1
    并发量不高,错峰抢票

    而你觉得线路上这么多站要加锁很复杂,其实并不是,每个站的票都是预先设定好的

    假设沿线 A, B, C 三个站,现实是会分给 A -> C 10 张票,A -> B 5 张票,A -> B 这个买完后就算 A -> C 可以继续也买不到 A -> B 的,虽然实际上这么乘车是没问题的
    limingjie138
        20
    limingjie138  
       2019-12-24 12:30:41 +08:00
    说不难的只考虑一节列车一个服务器,不考虑一个大区间有 N 多小区间?如果要整体区间来看全部满负荷,那么多小区间的分票算力就很费了好吧。还要考虑人工站点售票,两套系统操作一套 DB,系统如果系统难度还算可控,DB 这里怎么说。
    badcode
        21
    badcode  
       2019-12-24 12:31:58 +08:00 via Android
    @Raymon111111
    表示同意,
    下车时看到几乎整车厢的下车和上车
    maskerTUI
        22
    maskerTUI  
       2019-12-24 12:32:44 +08:00   ❤️ 9
    我觉得,火车票的逻辑比单纯一件商品的逻辑要复杂很多,就一条路线来说,其中一段行程的票被卖出去之后其它所有票都得重新计算,要考虑卖出去的是在哪一段(头部 /中间 /尾部),其它部分路段票数要不要减少,这样下来计算量是很大的;而淘宝的商品,大家各买各的,卖出去一件就库存减一。从个人观点来看,考虑到中国人口数量,我觉得是。
    Raymon111111
        23
    Raymon111111  
       2019-12-24 12:33:52 +08:00
    @badcode 我买票一致都是多花钱直接买到终点站,甚至都不用抢,慢悠悠的买就可以,我家那一站貌似就只有一两张票,刚出来就没了
    dodo2012
        24
    dodo2012  
       2019-12-24 12:34:55 +08:00
    真是无知者无畏啊,看 ls 一些估计连逻辑都不清楚,还来个不如个小电商的秒杀的理论了
    justrand
        25
    justrand  
    OP
       2019-12-24 12:35:37 +08:00
    @Raymon111111
    如果每个站对应每趟列车的每个区间网络售卖的票是固定的话,那逻辑确实很简单了。那么很疑惑 12306 的问题或者难点在哪里呢?
    momooy
        26
    momooy  
       2019-12-24 12:36:11 +08:00 via Android   ❤️ 6
    不要轻易对自己不懂的领域做评论,会被业内人笑话的
    Vegetable
        27
    Vegetable  
       2019-12-24 12:36:28 +08:00
    说 12306 不是最复杂的没问题,但是说什么就是一个小电商水平的,有点没过脑子吧
    czb
        28
    czb  
       2019-12-24 12:39:17 +08:00 via Android
    这个不能只看并发 也要看逻辑复杂度 双十一并发的确很大 但是逻辑也比较简单 12306 需要把座位利用率最大化就需要尽可能每一个区间乘客数量最大化 这中间的逻辑才是复杂的
    janus77
        29
    janus77  
       2019-12-24 12:42:36 +08:00 via iPhone
    看了下那位发言记录,戾气挺重的,先保平安
    hiya5
        30
    hiya5  
       2019-12-24 12:44:55 +08:00
    所以 V2 没有在 12306 的程序员吗
    nevin47
        31
    nevin47  
       2019-12-24 12:45:06 +08:00 via Android   ❤️ 5
    V 站的下限再次公开刷新了……
    woodensail
        32
    woodensail  
       2019-12-24 12:46:38 +08:00
    @eason1874 看清楚前提,我说的是单节点单 sku 在 shadring 后的抗压能力,而非系统抗压能力。所以你后面的话就显得很没有意义。
    justrand
        33
    justrand  
    OP
       2019-12-24 12:50:03 +08:00
    @Raymon111111
    我想了下,你的逻辑优点说不通,如果固定分配的,那岂不是有可能出现有些座位明明有票但是卖不出去的情况?<br>
    比如举个极端例子:<br>
    a-b-c 一共三站共 20 张票,固定分配 a-b 5 张 a-c 10 张 b-c 5 张 ,很特殊,a-c 这段区间乘客特别多,所以 a-c 一下子卖完了还剩下很多人买不到,但是正好没有 a-b 和 b-c 这样需求的购买人,那岂不是这列车卖出了 10 张票后其他票卖不出去了。这样的逻辑不行吧,如何保证座位利用率,车票应该是动态调整调配才符合逻辑吧,当然我也是瞎猜的
    ybbswc
        34
    ybbswc  
       2019-12-24 12:53:25 +08:00 via Android
    民科。我上我也行。😂
    gdrk
        35
    gdrk  
       2019-12-24 12:53:58 +08:00
    不会真有人觉得全球最大的票务系统简单吧,别恶心我。
    woodensail
        36
    woodensail  
       2019-12-24 12:55:20 +08:00
    @justrand 额,说的没错,所以 12306 的区间限售从非互联网时代起有一个令人诟病的点,就是全程票很足,区间票很少。导致很多人被迫买长乘短。

    12306 的想法是先满足全程乘坐的乘客,如果全程票多出来了,再在后面的批次分配给区间。然而大家不会真等到二次分配时再去买区间票,而是都去抢全程票了,毕竟如果全程票卖完了,也就不会再调剂给区间了……
    whp1473
        37
    whp1473  
       2019-12-24 12:57:03 +08:00   ❤️ 9
    12306 的业务很复杂,如果评的话,肯定能进中国前几名的复杂业务之一了。
    (1)高并发,虽然时段是拆分的,但是考虑到中国假期时间段,其实走和来一般都是开始和结束那几天,这 13 亿人都会参与的业务,每个人又有 N 个操作,N 次重复。
    (2)N 多刷票软件一直不停的刷,爬虫首要集中的业务
    (3)准确性要求极高,一旦出现超买、错买,会导致很严重的社会问题。不像有的小系统,数据错了,我再修修就好了。就问你敢修,一个逻辑写错了会同时面临新老逻辑交替,错误数据不断产生,在系统中蔓延
    (4)复杂业务,分布式事务、票务冲突、候补、区间车次买票、退票、改签、最大购票次数限制、如何合理分配票务和区间、如何保障各个节点尽可能利益最大化,这些都是系统要考虑的,点击一次买票不简单只是买票。

    这个业务一点也不简单!完全可以说是民用复杂业务之一,其他能比的估计就是股票高频交易、淘宝双 11 这类的了
    ifxo
        38
    ifxo  
       2019-12-24 13:09:33 +08:00
    就让腾讯或阿里做肯定没问题,所谓复杂不过是借口罢了
    woodensail
        39
    woodensail  
       2019-12-24 13:14:04 +08:00
    顺带一提,其实现在 12306 已经做得很不错了。
    读写分离,秒级更新,既保证数据正确性,同时可无限平行扩展,只要服务器够,哪怕全球一起刷都刷不挂。
    交易请求进队列,同时限制队列长度,既保证业务服务器稳定,又避免队列爆炸。当然缺点就是有人反馈明明看到有票,缺提示队列满。
    今年基本上也就候补功能出了些幺蛾子,考虑到候补售票是新上功能,首次抗压出点问题也可以理解。
    Counter
        40
    Counter  
       2019-12-24 13:17:13 +08:00
    并发是很重要的问题,但是不是唯一重要的问题
    Raymon111111
        41
    Raymon111111  
       2019-12-24 13:18:08 +08:00   ❤️ 3
    @justrand 不是完全固定分配的,但是票放出来那一瞬间不会是动态的,比如在发车前一天或者前几天,会慢慢把区间票再放出来。你真正去买下票就知道,始发站 ->终点站的票是最多的

    我这有个现成的例子,你可以现在去搜 1 月 16 号 G33 这趟车,这个车北京发车经过鹰潭,终点站是南昌。

    你会发现可以买北京->南昌的票而北京->鹰潭却是无票的
    WispZhan
        42
    WispZhan  
       2019-12-24 13:19:44 +08:00   ❤️ 1
    这上面一堆连需求都没分析清楚就开始 bb 了。
    wmhx
        43
    wmhx  
       2019-12-24 13:22:53 +08:00
    电商的系统, 基本单表的 curd 就可以搞定了, 这个只和技术有关,业务复杂度并不高 , 甚至可以允许一些失败. 所以很好切分压力;
    而 12306 可不是只要把票卖出去那么简单, 也要考虑利益最大化啊, 所以全程票最简单也最好卖,剩下分区间的就得各种动态组合分析才能知道怎么好卖了. 关键是不能多卖;
    而且我国的铁路系统总体是亏损的, 所以这类花钱的地方还是比较谨慎的.
    ilaipi
        44
    ilaipi  
       2019-12-24 13:28:34 +08:00
    @woodensail #7 12306 同时抢一个车次的一般不会超过一万人...

    我觉得这个超过一万人太正常了。。
    malusama
        45
    malusama  
       2019-12-24 13:30:33 +08:00
    话说现在 12306 上云也有阿里的参与啊。。
    bolide2005
        46
    bolide2005  
       2019-12-24 13:31:05 +08:00   ❤️ 72
    “12306 就是个普通小电商秒杀的水平”

    如果 V 站有年度金句投票的话,我想投这句话一票
    1194129822
        47
    1194129822  
       2019-12-24 13:34:29 +08:00
    有一年抢票给我抢了几亿次,每秒几百次,30 天不停歇,都没有抢到票,而像我这样的有多少。看技术解密,12306 每个节点内存都是 TB 为单位,一到高峰全是内存计算,只是一定时间才备份刷盘。
    tankren
        48
    tankren  
       2019-12-24 13:34:34 +08:00
    @whp1473 别的不说,哪来的 13 亿人参与
    woodensail
        49
    woodensail  
       2019-12-24 13:34:52 +08:00
    @ilaipi 以我的经验,真正准点抢票的话,成功率还是挺高的,考虑到我坐的车次总共也才 16 节,荷载 1200 人左右,看起来不像是有 1 万人再和我一起抢票的感觉。
    hsuvee
        50
    hsuvee  
       2019-12-24 13:36:08 +08:00
    12306 很复杂,但是以他们的实力和影响力,做这么烂是应该的?
    scnace
        51
    scnace  
       2019-12-24 13:36:20 +08:00 via Android
    nicevar
        52
    nicevar  
       2019-12-24 13:36:31 +08:00   ❤️ 4
    又到了暴露 v 友水平节目时间吗?上面有些人已经不是天真,是傻,这种人就是平时什么都没搞懂 BB 得很厉害,自己上的时候就跟傻子一样。
    12306 的复杂远超上面一些幼儿园儿童的想象,要黑之前至少去看一下以前的一些讨论分析,别上来就信口开河。
    JunoNin
        53
    JunoNin  
       2019-12-24 13:36:41 +08:00 via Android
    黄牛:我们被小看了?
    eason1874
        54
    eason1874  
       2019-12-24 13:36:41 +08:00
    @justrand #33
    @Raymon111111 #41

    节假期放票应该是各区别有一定预设比例的,根据城市人口等因素,就像会照顾农民工专门给窗口留票一样。动态调整肯定也有。这种东西应该跟红绿灯调度一样,有预案,但运营人员也要跟踪流量作出更优的动态调整。
    woodensail
        55
    woodensail  
       2019-12-24 13:39:21 +08:00
    当然,要论想坐某个方向的列车回家的人肯定多,但是不是所有人都会准点抢票,也不是所有人都和我抢同一个车次。所以说,抢票前记得定闹钟适合很好的习惯。我自从有一次大意,晚了半小时抢票导致没票以外,都习惯定闹钟了。
    eason1874
        56
    eason1874  
       2019-12-24 13:39:48 +08:00
    @eason1874 #54 打错字,是“各区间”,不是“各区别”。补充一下,我说的动态调整包括系统自动调度和运营人员调度,比纯粹的人工干预的系统复杂度要高。
    judeng
        57
    judeng  
       2019-12-24 13:42:07 +08:00
    v2 大佬真多。。。。。
    wangxiaoaer
        58
    wangxiaoaer  
       2019-12-24 13:49:13 +08:00   ❤️ 1
    都是瞎 jb 猜的,什么时候 12306 公开了售票机制,明确了需求再来讨论好吗?
    MYDTX
        59
    MYDTX  
       2019-12-24 13:50:20 +08:00   ❤️ 3
    看到楼上有人说,交给腾讯和阿里做肯定没有问题!
    难道支付宝服务器没有宕机过吗?难道微信支付没有出过事情吗?
    而且 12306 阿里云有参与哦,是真的抗不住!
    judeng
        60
    judeng  
       2019-12-24 13:52:06 +08:00   ❤️ 1
    @hsuvee “12306 很复杂,但是以他们的实力和影响力,做这么烂是应该的?”
    你是不是该补补脑子了,还是说阶级斗争的弦绷得太紧,没看到内容就开始喷了,楼上哪个人说的话能让你得出“做这么烂是应该的”这个结论的,莫非是从 13 年穿越回来的吗?
    lihua1358
        61
    lihua1358  
       2019-12-24 13:52:12 +08:00
    不是,线上业务本来可以简化提升速度的,但是很多原因会导致不能优化流程优化数据结构,导致的复杂度提高
    netherlanddennis
        62
    netherlanddennis  
       2019-12-24 13:53:30 +08:00   ❤️ 1
    lihua1358
        63
    lihua1358  
       2019-12-24 13:53:45 +08:00
    说不定还得加上 舍不得花钱加服务器扩容导致的复杂
    hst001
        64
    hst001  
       2019-12-24 13:57:23 +08:00
    我说是,就冲那个座位是实时变化的,跟做静态商品秒杀就不是一个级别的难度。
    hwdef
        65
    hwdef  
       2019-12-24 13:58:20 +08:00
    比淘宝肯定更难
    比亚马逊全球稍差。
    国内最难应该是没什么争议。
    npe
        66
    npe  
       2019-12-24 13:58:25 +08:00
    复杂是肯定的,但是为什么只在 6:00 ~ 23:00 提供购票服务呢?
    miniwade514
        67
    miniwade514  
       2019-12-24 14:00:21 +08:00
    N 年前就有大牛写文章分析过,为什么 12306 比淘宝京东都要复杂得多。
    https://www.guancha.cn/TMT/2014_01_11_199046.shtml
    fancy111
        68
    fancy111  
       2019-12-24 14:00:43 +08:00
    谢邀,12306 是业务最复杂的系统之一,但不是并发最高的系统之一。论并发量应该比不过双十一抢东西的时候,甚至可能比不过 GOOGLE 首页。因为春运抢票时间很长,按买票期 15 天算,1 亿人分摊开一天也只有 1 千万不到,分到每小时每分钟就更少了。实际上抢票人数是下降趋势,开票第一天最多,如果都登录 12306 进行刷票,瞬时并发确实高,不过下单时经历了确认订单、填验证码、提交订单等过程,实际上进行订单处理的并发并不高。而淘宝下单是无需验证码的,而且在获取网站信息的操作上两者区别不大,均是需要展现库存价格等信息。
    不过在复杂度上 12306 确实比淘宝复杂,淘宝只需要考虑单线逻辑,店铺-商品-人。而火车位置虽然是固定数量,但是路线交叉,座位可重复利用但不能同时段卖,时间不确定,人员记录多样化并且要跟其他系统交互等等。。。复杂度可想而知。
    liprais
        69
    liprais  
       2019-12-24 14:02:48 +08:00
    12306 现在事实上就是阿里做的,你猜猜比不比秒杀复杂
    netherlanddennis
        70
    netherlanddennis  
       2019-12-24 14:03:40 +08:00
    别看 12306UI 丑。就觉得他简单~~
    chaixiaomu
        71
    chaixiaomu  
       2019-12-24 14:07:55 +08:00
    12306 没请某些 v 友去设计,损失了好几万亿啊
    zhttty
        72
    zhttty  
       2019-12-24 14:09:22 +08:00   ❤️ 3
    12306 是世界上规模最大、业务最复杂、场景多变、安全性要求极高、淡旺季差异极大的实时交易系统之一,如果到了春运期间,可以把“之一”两个字去掉。

    62L 有知乎链接,楼上也有人发文章链接,可以去看看。希望大家不要张口就来,这跟老板让你三天做一个淘宝有什么不同?
    securityCoding
        73
    securityCoding  
       2019-12-24 14:11:03 +08:00
    楼上说简单的我估计写的接口扛不住几个爬虫
    cedoo22
        74
    cedoo22  
       2019-12-24 14:11:18 +08:00
    我想吹下阿里。。。从头开发一个新的并不难, 升级别人的系统才是牛逼的
    xiasohan
        75
    xiasohan  
       2019-12-24 14:11:19 +08:00   ❤️ 1
    @woodensail 以我的经验,你绝对是里家比较近才说出比较好抢票的话~~~
    xiasohan
        76
    xiasohan  
       2019-12-24 14:12:28 +08:00
    @woodensail 一方面想说一下负载 1200 人左右你是怎么知道的???难道是看有多少票吗??,那我就想问你做的是什么车啊 一个车厢怎么才做 75 个人啊,,并且也不是所有人都是手动点击啊,,,一般除了手动点击还有爬虫刷票还有各大收售票软件,,这些都是应该一起用的把~,,难道这些才一万人的并发吗?,,,
    crackhopper
        77
    crackhopper  
       2019-12-24 14:12:48 +08:00
    我看很多人都在讨论列车买票的问题。其实就是线段树算法就行了,并行上设计会稍微复杂点。嗯,强一致性、反作弊可能更难点。
    woodensail
        78
    woodensail  
       2019-12-24 14:13:07 +08:00
    @xiasohan 是的啊,所以数万人抢一张票还能抢到真不简单。
    woodensail
        79
    woodensail  
       2019-12-24 14:14:58 +08:00
    @xiasohan 荷载是是 12306 公布的,当然这里没算站票,算是站票算你 2000 人好了。
    xiasohan
        80
    xiasohan  
       2019-12-24 14:15:32 +08:00
    @woodensail 简直是太难了。我觉得 12306 是世界上规模最大、业务最复杂、场景多变、安全性要求极高、淡旺季差异极大的实时交易系统,说的没啥毛病
    xiasohan
        81
    xiasohan  
       2019-12-24 14:16:03 +08:00
    @woodensail 你是说一个车厢 2000 还是一共 2000 ?
    woodensail
        82
    woodensail  
       2019-12-24 14:18:06 +08:00
    @xiasohan 确实难啊,我也没说 12306 不难啊,主要是楼上一堆人都搞不清难在哪里。
    举例而言 12306 的反作弊系统就是个难点,要是没有反作弊系统做预筛,再长的秒杀队列也能被抢票机器瞬间刷满。
    1dian01
        83
    1dian01  
       2019-12-24 14:18:46 +08:00
    马云不是说 12306 的系统就是阿里巴巴做的吗
    woodensail
        84
    woodensail  
       2019-12-24 14:19:08 +08:00
    @xiasohan 一共,一个车厢看车型,一般在 60-100 之间,平均 80。16 节满编一般有 1200 个座位,然后还能再塞一点站票。
    xcstream
        85
    xcstream  
       2019-12-24 14:20:48 +08:00
    代码量能和 windows 比吗
    woodensail
        86
    woodensail  
       2019-12-24 14:21:22 +08:00
    另嗯,另外普速车能再多塞一些,不过最近这段时间正在逐渐把普速车往 CR200J 转,以后普速车会越来越少了
    20150517
        87
    20150517  
       2019-12-24 14:22:26 +08:00 via Android
    其实逻辑也没你们说的这么复杂,并发是很高,但切割点是在列车上,每部列车可以 sharding,不同列车之间班次排好后,互相没有影响。
    然后列车上,这逻辑确实看似复杂,因为存在 a 到 b,a 到 c 的不连续问题,这确实无法并发,但一列火车有多少站,能超过 20 站吗?站数越少,这种互锁情况越少,对于站数多的,互锁情况多的分配不同独立服务器,但现实情况是似乎所有火车购票都受到了影响,这是不是设计有问题,因为火车明明是可以 sharding 的啊?
    augustheart
        88
    augustheart  
       2019-12-24 14:23:39 +08:00   ❤️ 1
    我以为 12306 的复杂程度在三四年前就已经扫过盲了,没想到今年又有新的毕业生冒出来了啊……
    maplelin
        89
    maplelin  
       2019-12-24 14:25:50 +08:00
    楼上说简单的,怕是人均架构师起步?
    mnsw
        90
    mnsw  
       2019-12-24 14:29:32 +08:00
    @woodensail 民间架构师,厉害了!!!
    qq976739120
        91
    qq976739120  
       2019-12-24 14:30:25 +08:00
    我觉得不懂的东西别发绝对性的评论吧. “12306 就是个普通小电商秒杀的水平” 预定了 v2 年度傻屌?
    tz894305532
        92
    tz894305532  
       2019-12-24 14:34:18 +08:00
    @judeng 笑笑就行喽,真大佬哪有功夫摸鱼。
    arraysnow
        93
    arraysnow  
       2019-12-24 14:36:30 +08:00
    @gdrk 中国铁路流量上是最大的,数据量上最大的是印度铁路

    @woodensail 挺一下,个人认为 12306 最麻烦的是分布式和反作弊,难点并不在于并发和抢占。12306 的分布式缓存使用了毕威拓家的商用缓存系统,而不是常见开源组件,从这里能看出铁路票务分布式系统有很强的领域特性
    dedegg
        94
    dedegg  
       2019-12-24 14:41:17 +08:00
    年经帖( 1/1 )
    LuciferGo
        95
    LuciferGo  
       2019-12-24 14:45:19 +08:00   ❤️ 1
    @woodensail #10 一趟车假设 10 站,每站都有 30%上下,还有坐两站的,坐三站的,不同比例的坐站数,我就已经觉得没法简单算了,1000 只是车次的座位数,你想的太简单了
    wutongshuVVV
        96
    wutongshuVVV  
       2019-12-24 14:46:51 +08:00
    萌新仰望楼上大佬
    dawnYellow
        97
    dawnYellow  
       2019-12-24 15:02:10 +08:00
    有无往年旧贴
    sunziren
        98
    sunziren  
       2019-12-24 15:03:35 +08:00   ❤️ 1
    这楼让我见识到了自己技术的渺小。
    crab
        99
    crab  
       2019-12-24 15:06:38 +08:00
    @woodensail 这是校队 11 人可以踢赢皇萨 6 人阵容啊。
    x86
        100
    x86  
       2019-12-24 15:08:07 +08:00
    @woodensail #2 普通小电商你真敢说呢
    1  2  3  
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1192 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 60ms · UTC 21:27 · PVG 05:27 · LAX 13:27 · JFK 16:27
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.