北京-喜<-> 15:59:20
虽然难用，但12306面临的业务场景复杂度可能是世界之最. 先背书：文章里是内容我不是都赞同哈。 有兴趣一起讨论下。
北京-mrman(-) 16:05:18
整体表现上现在已经足够厉害了。
北京-luke(-) 16:06:12
静态final常量 有时候不会实例化类的
成都-梅小西(-) 16:07:01
喜神你说哪里不赞同了啊
北京-喜<-> 16:07:25
第一点 标题有误导
北京-luke(-) 16:07:27
静态方法不需要实例
杭州-绝之(-) 16:07:31
主要是个运筹学问题。
北京-喜<-> 16:07:35
所有的列车在线销售 都是这个复杂度, 并不是中国的-
成都-梅小西(-) 16:08:01
航班呢
天津-Michael(-) 16:08:07
中国的问题是人太多
北京-喜<-> 16:08:10
如果涉及拼车，那么中国因为车次多，那么只是量级的问题
北京-w(-) 16:08:15
西神 航班中途不下车
北京-喜<-> 16:08:19
问题的复杂度是一个啊
北京-w(-) 16:08:31
中转少的多
北京-喜<-> 16:08:38
航班的比不上这个
成都-过客(-) 16:08:39
看的脑壳痛
河南-Error<-> 16:08:57
复杂度和规模是两个概念。。
广州-扬帆(-) 16:11:13
火车的复杂度比航班大很多的
杭州-绝之(-) 16:11:14
我记得哪里说过-其实就是预先把票分区间，根本不用聚合根那么复杂
广州-扬帆(-) 16:14:10
超高并发下，不停的买票退票中途转车算起来就不容易了。
成都-梅小西(-) 16:17:37
我一直觉得火车票的存储，更新，非常复杂, 还得保持高并发, 比普通的电商秒杀还难吧
北京-喜<-> 16:18:11
最大全集是固定的，库存之间的交集关系是固定的,变化的是美团的销售状况, 变化的是美天的销售状况
北京-喜<-> 16:22:35
还得保持高并发 这个看策略, 搞清楚库存索引结构，才能谈这个问题。 因为这个时候才知道安全区到底是什么, 控制策略有2种：1种是全部悲观类， 1种排队控制+轮询
成都-梅小西(-) 16:23:57
排队控制。。。。类似队列了吧, mq
北京-喜<-> 16:24:11
其实就是同步还是异步, 整体还是强一致性, 同步就是 所有的库存都commit 成功 = 下单成功
北京-luke(-) 16:24:50
那就是分布式事务, 我想问一下 分布式事务 完全的强一致 用什么做？
广州-扬帆(-) 16:25:31
只能说原始库存是不变的，卖一张或退一张票就不是简单的少一张票或多一张票，可能涉及到几张票的问题的。在超高并发的情况下要算出来卖出去难度非常大了
北京-喜<-> 16:25:37
异步就是 每个库存有自己的commit 队列，前台下单等于往各个库存队列加了commit任务 ，前台轮询所有的commit队列状态，全部完成=下单成功, 关系是提前算好的, 不需要动态计算
北京-w(-) 16:27:32
喜神，我有个问题啊，比如有的同事买全称票就能买到，买这趟车的区间票就买不到，是不是可以说明他是有一部分提前规划好的呢
深圳–Rw (-) 16:27:53
这个我这次碰到了, 比如 我昨天能买 中间票的区间 ,结果今天 就查不到中间票的区间的 车次查询不出来, 但是实际上 票 我买了 也是有效的
北京-喜<-> 16:28:46
你想下库存本质上怎么分配和归类的, 你的问题是销售宽度的问题
深圳-平凡(-) 16:29:03
如果退票，不是涉及到库存重新计算了吗？
北京-喜<-> 16:30:22
退票和下单 没区别啊
深圳-平凡(-) 16:33:51
看位置是预先固定好了，还是可动态计算的。A-B-C-D，买了一张A-D的，那会影响B-C C-D 区间的库存。
南京-wyy(-) 16:34:16
还有a-c和b-d的也影响了
北京-喜<-> 16:34:55
这个关系是固定的啊, 在车次和城市确认之后，这个关系就确认了, 和用户买一段没关系。又不是用户引发的, 比如北京到大连的 K681，这个车次有多少个库存组合，是固定的。每天如此.
南京-wyy(-) 16:35:57
喜哥这意思是，A-D的票不会拆开卖？
北京-喜<-> 16:36:02
每天的销售情况是变化的
北京-w(-) 16:36:27
那如果某个段不够了 他会调整吗
成都-梅小西(-) 16:36:49
对，会调整么。
北京-喜<-> 16:37:11

经停站，包括上车站和途经站，不包括下车站，因为乘客不会占用下车站的座位
假设有N个车站，经停站是始发站的一共N-1种站点组合，终点站的组合数是0，经停站是第i站的组合数是i*(N-i)，0<i<=N
给一个车次的所有站从始发站编号，作为X轴，组合数是Y轴，绘制曲线，会形成一个等腰三角形（如果站数是偶数，就是等腰梯形，终点站不算在站数内）

每一个组合就是一个站段，就是一种售票的可能，可以把这一个站段想象成一个始发站是站段开头，终点站是站段结尾的虚拟列车
以始发站为例，一共N-1种组合，就要构造N-1个虚拟的列车
但是这些虚拟列车是可以重用的，这些虚拟列车覆盖的所有经停站都可以重用它们

票池维度包含车次和等级（软卧 硬卧 商务座 一等座 二等座 无座），无座可以认为是虚拟的座位
卧铺和座位编号可以是车厢编号+铺号/座号

要买某个站段的票，就是买这个站段对应的虚拟列车的库存

为每个站定义一个版本号，一个站作为经停站的所有站段库存数发生变化这个版本号就+1

这样就把一个需要频繁刷新库存数的操作减少到需要对经停站相关的库存数的操作

要买一张票，首先把相应站段的每一站作为经停站的所有虚拟列车指定等级的未售出票和未锁定票求交集，记为G
同时购买同一个车次的票的推入同一个队列，M个车次有且只有M个队列，队列内串行操作
从G中选择第一个位置，锁定，进入支付流程，处理队列中的下一个请求
支付失败或超时，解锁
支付成功座位被售出

假定有key是stations:上车站:下车站:车次:等级，可以从这个key查到指定站段、车次、等级的每一个经停站
假定有key是trains:经停站:车次:等级，可以从这个key指定经停站、车次、等级的每一个虚拟列车
假定有key是train:上车站:下车站:车次:等级，可以从这个key查到每一个座位
北京-喜<-> 22:04:14
@北京-哇咔咔 考虑数据模型和关系的时候，不考虑存储的。 库存那里可以不用虚拟列车，座位体系是对的, 模型只考虑关系和检索可达
北京-哇咔咔(-) 22:04:56
未售出票的交集怎么求, 北京-喜<-> 22:05:23
其实只有几个点：
1.库存和座位之间的关系
2.库存体系结构
3.座位体系结构
4.库存其实是可以发放的
5.销售阶段的购买物到底是什么，以及库存控制方案
交集是车次决定的.
北京-哇咔咔(-) 22:06:01
我想的是一个座位按一个sku算, 出票未出票是座位状态+库存状态, 一个座位有很多库存池，对应站点卖的直接就是座位, 不需要设计商品
杭州-Freedom(-) 22:07:13
我咋觉得，是个带数量的有向图
北京-哇咔咔(-) 22:07:47
我想过用图计算，觉的太复杂
北京-喜<-> 22:07:49
我说几个点的事情吧，有助于大家切分信息
1.列车造好之后，座位物理信息已经完成了
2.车次设计好之后，库存结构和各种售卖组合 已经完毕了, k车和d车 到底差别在哪 大家可以想一想.同样的起始站 终点站，和中途站的k和和动车.
3.座位和库存的关系。是在xx列车跑xx线路的时候确定的。依赖1和2.
上海-刹那芳华(-) 22:10:25
北京-徐州东-南京南-上海
如果徐州东-南京南完了 北京到上海是不是页完了？
杭州-七月(-) 22:10:51
不是这样想把
杭州-受气包(-) 22:10:55
不是, 会预留北京到上海的票
北京-喜<-> 22:11:24
这个是库存调拨的事情, 列车、座位、线路、车次, 基本就这3-4个数据结构
杭州-Freedom(-) 22:13:11
带数量的有向图，其中任何一个线段数量达到总座位数，那一段路程就不能售卖
北京-喜<-> 22:13:13
今天已经说过了, 车站的柜台售票也是用的这一套, 根本不是-设计的, -是处理互联网流量的
杭州-受气包(-) 22:14:01
@北京-喜 然而作为火车站售票员的闺蜜屁都不知道
北京-喜<-> 22:14:05
比柜台流量和并发度大而已
上海-刹那芳华(-) 22:14:07
我一直挺好奇，为啥-自己不做云，他这个可比双11和黑5难度大多了啊
北京-喜<-> 22:14:22
后台的结构支撑是一样的。网络和柜台没区别, 难度不大, 没想清楚而已, 他现在的拼车确实-独有的, 柜台没这个模式, 这里是把库存追加了一个维度因子，到站时间, 这个到时候一起说下
杭州-cc爱冒险(-) 22:16:31
-，马云说了，这个烂摊子他免费接手。现在用的就是阿里云
北京-喜<-> 22:16:53
-原本烂, 不是人家的模型烂, 只是没有互联网流量应对经验而已, 模型是复用的柜台的
杭州-受气包(-) 22:18:06
@上海-刹那芳华 但是如果按照你说的，中间票卖完了，全程票就买不了了，那黑牛不是只要买一站票就把火车站的票全给占了
北京-哇咔咔(-) 22:18:36
他得包车才行
北京-喜<-> 22:18:49
库存结构和库存状态是2件事啊, 有些库存可以不上架售卖. 按照历史订单、站点规模和收益模型, 决定这个点的库存结构，上不上线. 小站：？比如乡镇站点。 它的库存结构和其他城市没区别, 但是覆盖范围，是可以挑拨的, 有个最大构成和售卖构成的问题, 库存的体系结构和最大分类构成, 但不表示全部都拿上去卖, 按站点分配的时候，可以设置的.
北京-行知(-) 22:26:28
有个问题 如果剩下一个全程的票 但是多个人要买分段的票 组合起来正好是全程的 此时到底应该不应该卖给他
北京-哇咔咔(-) 22:26:56
当然卖了, 这个就是座位和库存的关系
北京-喜<-> 22:27:02
你好好想想
杭州-受气包(-) 22:27:36
问题是系统不知道第一个分段客户来的时候会不会有后面几个刚好匹配的分段客户啊
北京-喜<-> 22:27:40
这个座位卖完了真的就没票了么, 随所以没有最优解，跟输入有关系
成都-Noexcuse(-) 22:28:08
站票
北京-喜<-> 22:28:16
不是站票
北京-哇咔咔(-) 22:28:17
下一段的还有票，但是包含这一段的没有了
杭州-受气包(-) 22:28:19
会不会卖了这个分段客户，后面刚好来个人要全段票
北京-喜<-> 22:28:28
座位是多站售卖的
杭州-受气包(-) 22:28:28
这时候又没有了
北京-行知(-) 22:28:35
所以 这个其实是没有最优解的
南宁-为两餐(-) 22:28:57
分段与全程有优先级的区别了
北京-喜<-> 22:29:13
座位在每种站点组合里，都有1个库存, 站点组合 取决于线路, 比如北京到上海 是线路, 北京到上海的 D41 ，这个是车次, 站点有等级，基本就是行政等级, 这个会影响库存数量（其实就是站点组合问题，座位数量/座位类型） ,座位x站点组合 = 所有库存, 这里可以给座位加限制条件，可以给站点组合加限制条件
杭州-Freedom(-) 22:32:47
每一个车次的每一个座位，是一个单独的有向图；一列车如果有200个座位，就是200个有向图；一个有向图上，任何一段被占了，就只能售卖段前、段后的线段
北京-哇咔咔(-) 22:32:51
现在我觉的@Freedom 的做法更简单了
北京-喜<-> 22:32:58
影响 最后的那个 所有库存的集合大小而已
北京-哇咔咔(-) 22:33:17
不用有向图，一个无向图就行, 确切的说是一个N叉树
杭州-Freedom(-) 22:33:47
站点有顺序，所以要用有向图
北京-喜<-> 22:36:34
后续用 from to就搞定了, 有序, 你的图就是库存发放的事情, 到时候一起说了，你是把2个问题放在一起说了, 座位x站点组合的时候, 可以决定一些站点不参与进来, 也可以指定哪些座位类型和车厢 进来
珠海-吴彦祖居士(-) 22:42:00
我回家的春运票，一开始只会始发到终点有票，中间全部没票的
北京-喜<-> 22:42:03
业务和模型之间的关系啊, 模型是可以支撑各种业务的 ,但是业务不是模型的数据结构, 应该是全段票优先卖, 上次讲A+B 商品=C商品的，可以使用积分, 已经说了背后的思考逻辑
北京-五道杠(-) 22:44:16
如果-很“蠢“ 车次+站间+座位是唯一的 提前动态规划+预留
北京-喜<-> 22:45:14
没有做过商品上架逻辑的同学么？ 把一间房分小时座位小时房售卖的逻辑, 库存和时间的关系, 什么时间可买，库存的级联关系, 哪些房间可以卖小时房, 不同房间，比如有的17点就不卖了。有的可以卖到20点, 和铁路售票是一个问题啊
成都-孤狼(-) 22:49:28
这种是怎么玩儿的呢？
北京-喜<-> 22:50:09
穷举库存组合和库存关系, 至于上架的时候是不是上架, 是可以按房型分类、时间等约束的, 产出的可用库存结构 范围不同, 这个时候用户还没进来买呢, 所以这个和用户没关系，别把用户带进来, 用户实际购买后，找到那个库存，锁定
成都-孤狼(-) 22:53:21
简化成商品类型——>业务规则？
北京-喜<-> 22:53:23
并把跟它有交集关系的库存，都锁定支付了，直接库存是售卖, 交集关系的库存是无效,关联库存是怎么生成的, 以时间为例：售卖时间是12-20点，小时房3小时, 所以库存时间是12-17点, 12点+3=15，所以和13和14库存有级联关系, 每个小时都有1个库存, 12点买的时候，把13 14的一起锁定了, 买13的时候，也影响这个房间的12点和14点 15点的库存,房间=座位，时间=站点, 某个站点的某个座位不卖，或者数量限制。是在上架的时候就决定的.
成都-奋斗(-) 23:11:55
穷举库存组合，然后没有最优解所以才会有上车补票的存在
北京-喜<-> 23:13:35
车上售票机 查的库存状态系统, 跟-在线和车站柜台查的是一套
杭州-受气包(-) 23:13:58
上车补票都是没坐的啊
北京-喜<-> 23:14:07
所以为啥我一直说这个不是-设计的
杭州-cc爱冒险(-) 23:14:09
@北京-一粒沙 莎莎，下个“智行火车票”APP，他有预约和抢票功能，其实都是抢票。
北京-喜<-> 23:14:17
他只是互联网售票通道
杭州-受气包(-) 23:14:28
这个需要查系统么？不是只要人站得下就能补么
北京-喜<-> 23:14:41
不是, 有的座位 乘客没来, 可以卖这个座位号
杭州-受气包(-) 23:15:03
那票面也是无座的
北京-喜<-> 23:15:07
或者库存在上架的时候没分
杭州-受气包(-) 23:15:23
只是人们自己看到空座就坐了而已啊
北京-喜<-> 23:15:42
这个也是业务 其实结构是能支持的
杭州-受气包(-) 23:16:07
所以我觉得补票不用查系统
深圳阿程<-> 23:17:20
补卧铺的时候 ？？
北京-喜<-> 23:17:22
都可以, 看业务
杭州-受气包(-) 23:17:54
嗯，请继续
北京-喜<-> 23:18:01
站票换个角度是无库存上限的
深圳阿程<-> 23:18:02
特别长途车 经常有列车员喊 有卧铺 咋打出来的票
北京-喜<-> 23:18:20
也没有物理座位信息 只有车厢, 座位x站点组合, 站票严格不等于座位, 可以虚拟化个座位 也可以不, @深圳阿程 这个肯定走, 所以讲的话 一般是铁路售票系统, 根本不提-, 讲-就讲流量和体量问题，这个没啥好讲的
深圳阿程<-> 23:21:52
他们得票肯定是分车 车厢 然后分段的 一般一个长途车 不会每个车型都搞短途
北京-喜<-> 23:21:58
在吹牛逼的话，这也是前台和中台架构
杭州-受气包(-) 23:23:22
就是直觉上不习惯枚举
成都-奋斗(-) 23:23:45
喜神如果穷举座位与站的组合，那么一辆车就会有n个组合了，卖出一个座位就少几种组合，还有就是最优解这个他咋确定的?
北京-喜<-> 23:24:30
没有最优解啊, 完全看乘客分布, 大家都买1站才好呢, 也得看计费规则啊,不一定是整体收入最大
成都-奋斗(-) 23:25:28
估计也有优先级考虑
北京-喜<-> 23:25:51
每个站都是5块, 加一站加5块, 你可以算算怎么玩最大利益
成都-奋斗(-) 23:26:16
随开车时间越近，估计某个时刻就全部放出票
北京-天空<-> 23:26:18
现在-的规则之一就是先放出来的始点到终点的票
北京-喜<-> 23:26:25
再比如里程计费的
成都-奋斗(-) 23:26:35
先把价钱最高的卖了
北京-天空<-> 23:26:40
不是
成都-奋斗(-) 23:26:43
外卖短程
北京-喜<-> 23:26:43
@北京-天空 上架加个时间就可以了啊, c端可见性, 不等于后台数据集
北京-天空<-> 23:27:06
还有分时间段放票
成都-奋斗(-) 23:27:27
他是不是提前生成好了数据放库
北京-喜<-> 23:27:28
所有库存都初始化好了, 只是你看不到而已, 秒杀不都这样么
成都-奋斗(-) 23:27:56
然后根据规则的可见性
北京-喜<-> 23:28:01
对啊
杭州-Freedom(-) 23:29:58
每一个有向图的线段组合，都是生成好的，每卖出一张票，去匹配符合条件的组合就行了
成都-奋斗(-) 23:30:33
为啥是有向图，不能是无向图么
杭州-Freedom(-) 23:30:33
卖出的票越多，剩余的组合数越少
北京-天空<-> 23:31:07
@杭州-Freedom 问题的根源在并发上，因为春节全国人群大迁徙
杭州-Freedom(-) 23:31:25
@成都-奋斗 站点有顺序
北京-天空<-> 23:32:19
业务上优化比技术上的优化要来的显著
上海-刹那芳华(-) 23:32:23
用图的话，肯定是有向的啊
成都-奋斗(-) 23:32:28
难点在于车位和站点组合
北京-喜<-> 23:32:36
@杭州－东子 中台的解释还可以，过得去。前台解释错了
杭州－东子(-) 23:33:52
我理解的前台就是各个渠道，比如说咸鱼，天猫，淘宝，这些入口, 看完这个文章之后[是的]
成都-奋斗(-) 23:35:07
中台我有点没有懂的是。n个业务，每个业务执行的流程节点不一致，是怎么执行的，根配置的每个业务执行节点么
北京-喜<-> 23:44:36
@成都-奋斗 节点基本是一致的， node的最大集是一样的，业务决定哪些node参加，可以使用配置，也可以硬编码

北京-哇咔咔(-) 2018/02/24更新
经停站，包括上车站和途经站，不包括下车站，因为乘客不会占用下车站的座位
假设有N个车站，经停站是始发站的一共N-1种站点组合，终点站的组合数是0，经停站是第i站的组合数是i*(N-i)，0<i<=N
给一个车次的所有站从始发站编号，作为X轴，组合数是Y轴，绘制曲线，会形成一个等腰三角形（如果站数是偶数，就是等腰梯形，终点站不算在站数内）
每一个组合就是一个站段，就是一种售票的可能，可以把这一个站段想象成一个始发站是站段开头，终点站是站段结尾的虚拟列车
以始发站为例，一共N-1种组合，就要构造N-1个虚拟的列车
但是这些虚拟列车是可以重用的，这些虚拟列车覆盖的所有经停站都可以重用它们
票池维度包含车次和等级（软卧 硬卧 商务座 一等座 二等座 无座），无座可以认为是虚拟的座位
卧铺和座位编号可以是车厢编号+铺号/座号
要买某个站段的票，就是买这个站段对应的虚拟列车的库存
为每个站定义一个版本号，一个站作为经停站的所有站段库存数发生变化这个版本号就+1
这样就把一个需要频繁刷新库存数的操作减少到需要对经停站相关的库存数的操作
要买一张票，首先把相应站段的每一站作为经停站的所有虚拟列车指定等级的未售出票和未锁定票求交集，记为G
同时购买同一个站段、车次、等级的票的推入同一个队列，队列数是这些维度的组合数，队列内串行操作
从G中选择第一个位置，锁定，进入支付流程，处理队列中的下一个请求
支付失败或超时，解锁
支付成功座位被售出
假定有key是stations:上车站:下车站:车次:等级，可以从这个key查到指定站段、车次、等级的每一个经停站
假定有key是trains:经停站:车次:等级，可以从这个key指定经停站、车次、等级的每一个虚拟列车，用“上车站:下车站:车次:等级”表示
假定有key是seats:上车站:下车站:车次:等级，可以从这个key查到指定站段、车次、等级的每一个座位，座位中记录是否售出或锁定