20180108-针对12306面临的业务场景复杂度的一场头脑风暴

北京-喜<-> 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


成都-梅小西(-) 16:37:14
每个中间站到中间站的票,都是提前预配好的么
深圳-rubin(-) 16:37:16
是指一开始就规定了途径A-D的多少张票?A-B多少?
北京-喜<-> 16:37:29
所有的库存都是预先配置的
深圳-rubin(-) 16:37:32
受教了
北京-喜<-> 16:37:41
这个是车次的维度的
成都-梅小西(-) 16:37:47
哦。原来是这样,不会后面再计算啊
北京-哇咔咔(-) 16:37:49
如果要动态计算,假如有且只有一趟车的票可以卖,北京到上海,途经济南。我要买去济南的票,就要锁住从北京到济南每个站作为上车站的所有票,这个代价太大
南京-wyy(-) 16:37:51
@北京-喜 这就变成了普通的电商系统了
北京-喜<-> 16:37:59
和在线销售,还是车站线下买没关系
深圳-平凡(-) 16:38:06
看业务诉求吧,部分库存允许动态计算能根据实际坐车需求进行调整,更合理
北京-喜<-> 16:38:22
挺多是会按销售渠道、终端,去划拨库存在哪个端售卖, 不需要动态划拨
北京-哇咔咔(-) 16:38:40
线下卖票也是这么干的,按车次和站段分票池, 每个票池有固定数量的票
北京-luke(-) 16:38:43
现实中的站票这个怎么算进去呢
北京-喜<-> 16:38:49
每天最大库存售卖量 就是每个人都只做1站
北京-哇咔咔(-) 16:38:59
随着运营会调整,但是不频繁
北京-喜<-> 16:39:04
最小售卖量就是 每个人 都从起始点坐到终点, 所有的库存 穷举出来
广州-小护士<-> 16:39:28
路径越长,售票库存越少
北京-哇咔咔(-) 16:39:41
很多时候车上明明还能站人,但是无座票也不卖了
深圳-平凡(-) 16:40:03
@北京-喜 你说的是文章里的穷举,对应区间减1?
北京-喜<-> 16:40:16
就是N的阶乘...库存的直接一级维度 是 起始站 + 抵达站, 通过这2个值,能检索他的所有交集库存集合,
这个关系都是不会变的,预先固化好的
广州-小护士<-> 16:39:28
路径越长,售票库存越少
北京-哇咔咔(-) 16:39:41
很多时候车上明明还能站人,但是无座票也不卖了
深圳-平凡(-) 16:40:03
@北京-喜 你说的是文章里的穷举,对应区间减1?
北京-喜<-> 16:40:16
就是N的阶乘...
北京-喜<-> 16:41:00
库存的直接一级维度 是 起始站 + 抵达站, 通过这2个值,能检索他的所有交集库存集合, 这个关系都是不会变的,预先固化好的
北京-(-) 16:42:16
这样做起来简单啊 预先配置 售罄为止
北京-luke(-) 16:42:33
现实中也应该是这样的
北京-喜<-> 16:42:35
是因为这个关系不会变
北京-C_C(-) 16:42:37
座位是一定的
北京-喜<-> 16:42:42
所有中间加了1个车站, 重新刷一下就好了。 刷新算法是固定的, 输入N -> 输出所有库存组合
北京-chris(-) 16:43:06
这样就影响到公司盈利
北京-luke(-) 16:44:13
座位和车站区间也是关联的吧
天津-Michael(-) 16:44:19
1级检索车次,2级检索区间库存
北京-喜<-> 16:44:23
这个是最直接的关系, 还有一些别的关系, 库存和座位之间是关联的, 座位 有车厢号、座位等级
北京-luke(-) 16:45:06
也就是说 座位号其实是和车站区间是关联的 这都是预先设计好的
北京-喜<-> 16:45:14
对的
北京-喜<-> 16:45:25
这个是这条线路开通的时候,就确认的啊, 和售卖侧 还没关系呢, 在-有之前, 难道站点直接买票 不是这样么?
北京-luke(-) 16:46:14
对 就是这样的 现实中就是如此
北京-喜<-> 16:46:21
以为这个是-设计出来的?
北京-luke(-) 16:46:28
站票也会和车次区间关联吧
北京-喜<-> 16:46:37
站票也要关联
北京-luke(-) 16:46:41
那就对了
北京-喜<-> 16:46:47
这个就是索引结构 和 聚合维度的事情, 落地其实是双向检索, 有人说自己的抽象概括、业务梳理、理解比较好的时候,可以问他这个问题
杭州-光明消逝(-) 16:49:19
车票的算法,想想都头疼,各种什么二个人一起买,三个人一起买,优先匹配短程买过不冲突的
北京-喜<-> 16:49:33
没啥啊, 就是给什么库存而已, 他们之间是库存宽度是一致的
北京-luke(-) 16:49:57
其实现实的做法挺简单的
北京-喜<-> 16:49:58
起始站和抵达站 是一个啊, 分配算法 和 库存结构没什么关系啊, 分配算法 是看已销售情况、历史情况、收益模型什么的, 决定给什么库存而已, 跟库存自身的结构,没什么直接关系
上海-阿贵(-) 16:52:06
现在 提前抢票 是按照什么来的, 不同软件 抢票 速度 是不是不一样
北京-C_C(-) 16:52:11
站点:A B C D 座位:1 2 你怎么存
杭州-光明消逝(-) 16:52:27
我觉得,库存的依据是座位.[是的]
北京-喜<-> 16:52:46
抢票和这个没关系,抢票是各个公司用抓取抓的-
北京-luke(-) 16:53:09
不同的座位对应不同的乘车区间 比如A站到B站的座位为一车1,2,3号
北京-喜<-> 16:53:28
但是是2套体系啊
山东-仲夏(-) 16:53:31
站票库存依据什么
北京-喜<-> 16:53:33
之间只是配对关系
北京-luke(-) 16:53:46
肯定都是抓取-的 不可能自己去直接搞票
北京-喜<-> 16:53:48
并不影响 座位体系和库存体系的分开设计
成都-无名(-) 16:54:06
-的tps达到多少了?
北京-喜<-> 16:54:08
座位 X 库存, 库存 是按站点 穷举的
杭州-光明消逝(-) 16:55:19
结构应该是 A1座位, 然后1~10站10个区间,买一A1座票就是 57区间被占用,还可以用14,8~10
北京-luke(-) 16:55:21
@北京-C_C 我的理解是是的 只是座位号可能变成456
杭州-bz-java(-) 16:55:51
库存的单位是 车号-班次-站点-座位的元祖更科学点吧..
北京-C_C(-) 16:56:43
那如果我买了其中的一段,那么所有的组合都得重新更新一遍?
北京-liunx(-) 16:56:50
不会
北京-luke(-) 16:57:11
不用重新排列 都是之前就排列好了
北京-C_C(-) 16:57:17
什么叫先分配
北京-liunx(-) 16:57:21
给这一段10张票,这一段只有10张
杭州-bz-java(-) 16:57:34
我上面说的是自己的想法 操作起来更简单点
北京-luke(-) 16:57:48
@北京-liunx 我也是这么理解的
北京-喜<-> 16:57:49
库存就是座位的啊
杭州-bz-java(-) 16:57:51
车票的话就变成卖商品组合了...
北京-喜<-> 16:58:01
你说的是 检索方式 和 聚合维度, 没商品什么事, 理论上不需要商品模型
杭州-bz-java(-) 16:58:33
我定义的是库存, 我自己的想法
北京-liunx(-) 16:58:43
那那种包含关系怎么分配票数呢?
北京-luke(-) 16:59:04
估计是根据经验
北京-liunx(-) 16:59:40
就比如 A到E B到D 因为AE数量要包括BD的数量
北京-喜<-> 16:59:49
AE有自己的啊, 只是销售出去之后,需要刷级联的库存
北京-liunx(-) 17:00:12
那bd的数量也不能大于ae吧。
北京-luke(-) 17:00:16
@北京-liunx A-E的是单独的一系列座位 B-D是单独的另一系列座位 不冲突 我的理解
北京-喜<-> 17:00:17
级联 = 有交集, A-E会有它自己的级联联系, 这个都是不会变的,车次和车站确认之后,都确认的, 咋就理解不了这个了?A-E 会影响 A-E之间的所有组合
北京-luke(-) 17:02:01
我当年在东北坐火车时 买到站票的话 都是碰运气看有没有座位 所以感觉不同区间之间应该没联系
北京-liunx(-) 17:02:05
少想了座位。
北京-喜<-> 17:02:07
这个关系是固定的,车次上线售卖的时候,就确认的, 你买的哪一段,先更新这一段的库存, 然后去关系里检索被影响的库存集, 都刷一下, 对于同一个座位,可能别人在买另外一段,和你其实冲突了
北京-liunx(-) 17:03:14
恩恩。
北京-喜<-> 17:03:15
如果人家买G-I , 其实和你也没关系
北京-luke(-) 17:03:30
对 但这个座位属于不同区间段 你下车了 他就上车 其实不冲突
北京-喜<-> 17:03:31
这个就是前面说的 安全区, 库存结构想不清楚的话。实际冲突的到底是什么,也就想不清楚, 然后 现在-的拼车,其实就是基于这个双向库存结构的, 按车次和站点 固化下的库存结构, 库存和座位之间的关系, 按车次、站点、座位等级 -> 座位 的关系, 站票只是个座位等级, 可以在信息上设计一个虚拟座位, 座位的物理信息里 有车厢 和 二维结构(横排和竖排,比如 3A)
北京-luke(-) 17:08:36
虚拟信息就是这个座位属于哪个区间段 比如A-B B-C I-G这类的 我的理解
北京-喜<-> 17:08:46
不是, 因为站票是没有实际的物理座位的, 在出票的信息上。站票没有二维信息而已. 库存结构上,是一样的.
北京-luke(-) 17:09:33
对 站票是没有的 但要保证每个区间段内 站票数量+坐票数量 不能超过负载
广州-小护士<-> 17:09:47
站票只有车厢容量?
北京-喜<-> 17:10:05
所以前面说的 买全程有,买中间没有的问题, 都是销售策略和库存调拨的问题, 不是库存结构的问题,
这个是在库存结构之外,又包了一层体系 是另外一个事
北京-luke(-) 17:11:31
不过有时候也不这么严格 我从我对象她家回北京经常就是站票 都是上车了补票 人数不是特多的话 不会超载
北京-喜<-> 17:11:47
比如超过5个站点,就不生成哪种库存
北京-喜<-> 17:12:00
比如不生成就1个临界站点的, 3个站点以上跨度才生成, 这些都是策略
北京-luke(-) 17:12:51
其实你们去铁路里实地观察一段就知道了 前提是有机会进去 , 现实中的做法比想象的要简单
北京-喜<-> 17:14:11
有人整理么,我可以搞个专题分享下
北京-(-) 17:15:21
其实网上好多人都讨论过-的业务和解决方案 但是感觉想的还是简单了
北京-喜<-> 17:21:17
今天的内容如果有人整理的话,我可以复用一部分
北京-喜<-> 17:21:33
没人整理的话 我就要重头写。这个我以前没专门整理过
北京-哇咔咔(-) 17:28:11
买一个站段的一张票,要刷一遍跟这一段有交集的所有站段的库存,这样会不会有点慢啊?[只是个引用关系啊, -买票的RT高,就是因为这个, 有2种刷新策略 ,各有优劣, 我在写会员业务的本质,这个写完,才能写铁路销售 ]
杭州-bz-java(-) 17:33:19
这就是设计和实现上的区别了..
上面说程序员会把事情想复杂有一定的原因是没有/不知道很好的实现方案
被强行圈到了自己熟悉的架构/框架里去回答了...
北京-行知(-) 17:34:45
是啊,设计阶段不应该去考虑实现细节,这些是落地的时候才去考虑的
北京-哇咔咔(-) 21:40:46

经停站,包括上车站和途经站,不包括下车站,因为乘客不会占用下车站的座位
假设有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查到指定站段、车次、等级的每一个座位,座位中记录是否售出或锁定

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 199,271评论 5 466
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 83,725评论 2 376
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 146,252评论 0 328
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 53,634评论 1 270
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 62,549评论 5 359
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 47,985评论 1 275
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 37,471评论 3 390
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,128评论 0 254
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 40,257评论 1 294
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,233评论 2 317
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,235评论 1 328
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,940评论 3 316
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 38,528评论 3 302
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,623评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,858评论 1 255
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 42,245评论 2 344
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 41,790评论 2 339

推荐阅读更多精彩内容

  • 曾经有一份美好的爱情放在我的面前我没有珍惜。等到失去后才后悔莫及。如果可以再对小李说。毛欣想说。这辈子无缘再牵手。...
    毛欣与小李阅读 2,528评论 0 13
  • 摘要: 订单. 库存. 规则引擎. 业务漏洞. 1. 认同么?《逆流而上 阿里巴巴技术成长之路》[成都-梅小西]...
    六月星空2011阅读 434评论 0 1
  • 7点30起床 送小马上学 回来洗了下吃了点东西 上班去了 10点20到的 没有完成准时到的想法 但这次回来已经打破...
    肖博文阅读 148评论 0 0
  • 今天是二零一七年十月二十四日农历九月初五,现在是13:33分,我在长沙。 长沙今天的天气很好,晨有薄雾,午后却...
    离三白阅读 276评论 0 0