B****D
发帖数: 132 | 1 先声明, 不清楚目前系统的问题. 只看了两眼讨论.
我觉得, 从THINK OUT OF BOX 角度来说, 火车订票不一定需要跟飞机定票一样的下单
出票. 做几个假设.
1. 假设运力小于需求量.
在这个前提下, 火车出票还需要做到尽可能地把每辆车塞满. 因此, 它还是个座位优化
问题. 我坐高铁注意到这个问题. 起发站坐满了. 中间人下去了, 很长时间内空着, 到
了个大站又上满了.
2. 火车可以有一定数量的站票. 这跟飞机不一样. 事实上, 飞机定票在高峰期一般也
是略微过订的, 否则也不会有在机场喇叭广播谁愿意晚一班, 白给200元的事情了.
3. 春运的人, 一般时间上有弹性. 早一天, 晚一天, 只要不过了大年三十, 很多人不
在乎. 同样, 是早上十点, 还是下午两点的火车, 大多数人不在乎.
4. 春运期间, 可以临时加火车.
我觉得一种可行的办法是:
1. 每天12小时让旅客下单. 当场不出票, 第二天出. 这样, 只有前台有压力, 后台只
需要记录需求, 不需要加锁查看资源.
2. 每个旅客只能下两单, 春节前一单, 之后一单. 多下的单自动被取消. (或者让旅客
自己选择取消).
3. 旅客需要给出时间选择. 必须当天的加10%车费, 灵活的不加. 必须某车次的加10%
车费, 灵活的不加. 假设有10,000个车站, 那么总共有1亿种可能的旅行请求. 这个可
以事先预处理, 对每种请求给出三到五种选择, 让旅客选择排序.
4. 当每天的所有单都下完后, MAP REDUCE 查看每车次每站的需求. 然后根据现有车票
情况进行优化调整. 每车次可以上浮2% 的站票. 如果某车段严重超载, 可以考虑加一
车次.
5. 第二天统一对前一天请求出票. | s*****e
发帖数: 16824 | 2 你这个假设有问题，回去过年的人不是对时间不敏感，而是非常敏感。第一，假期有限
，早一天回家就多享受一天假。第二，很多人下了火车还要转汽车，点对不上很麻烦。
第三，很多活动比如年夜饭都是很早就订好的。所以买票人必须实时知道票买到了没有
。如果拖到第二天才知道那可能整个行程就毁了。而且不实时的系统容易被怀疑有人为
做手脚。
【在 B****D 的大作中提到】
: 先声明, 不清楚目前系统的问题. 只看了两眼讨论.
: 我觉得, 从THINK OUT OF BOX 角度来说, 火车订票不一定需要跟飞机定票一样的下单
: 出票. 做几个假设.
: 1. 假设运力小于需求量.
: 在这个前提下, 火车出票还需要做到尽可能地把每辆车塞满. 因此, 它还是个座位优化
: 问题. 我坐高铁注意到这个问题. 起发站坐满了. 中间人下去了, 很长时间内空着, 到
: 了个大站又上满了.
: 2. 火车可以有一定数量的站票. 这跟飞机不一样. 事实上, 飞机定票在高峰期一般也
: 是略微过订的, 否则也不会有在机场喇叭广播谁愿意晚一班, 白给200元的事情了.
: 3. 春运的人, 一般时间上有弹性. 早一天, 晚一天, 只要不过了大年三十, 很多人不
| s*****r
发帖数: 43070 | 3 铁路长途车会有区间限售，春运期间基本都是点到点销售，不会只卖一小段车票。优化
原则就是，从起点开始，离终点越近越好。不少人买不到中间站的票，就只能买到终点
的。
【在 B****D 的大作中提到】
: 先声明, 不清楚目前系统的问题. 只看了两眼讨论.
: 我觉得, 从THINK OUT OF BOX 角度来说, 火车订票不一定需要跟飞机定票一样的下单
: 出票. 做几个假设.
: 1. 假设运力小于需求量.
: 在这个前提下, 火车出票还需要做到尽可能地把每辆车塞满. 因此, 它还是个座位优化
: 问题. 我坐高铁注意到这个问题. 起发站坐满了. 中间人下去了, 很长时间内空着, 到
: 了个大站又上满了.
: 2. 火车可以有一定数量的站票. 这跟飞机不一样. 事实上, 飞机定票在高峰期一般也
: 是略微过订的, 否则也不会有在机场喇叭广播谁愿意晚一班, 白给200元的事情了.
: 3. 春运的人, 一般时间上有弹性. 早一天, 晚一天, 只要不过了大年三十, 很多人不
| g*****g
发帖数: 34805 | 4 优化啥呀，每天1000趟车，一趟车3种座位，20个区段，就当作6万种商品，每种商品有
个计数器。
下单就是把所有的跑的段－1。 RDBMS transaction保证integrity, 前面都算过，每天
放票10次，每次
最多4分钟也处理完了。 | B****D
发帖数: 132 | 5 这么说吧, 有些人对时间敏感, 有些人不敏感. 如果对时间要求高, 多交钱就好了.
也可以实时出票, 加一倍钱就好了. 等大家发现等一天出票也很可靠后, 想实时出票的
人就少了.
对系统的怀疑不是问题. 开源,请多家公司联合鉴定都可以.
【在 s*****e 的大作中提到】
: 你这个假设有问题，回去过年的人不是对时间不敏感，而是非常敏感。第一，假期有限
: ，早一天回家就多享受一天假。第二，很多人下了火车还要转汽车，点对不上很麻烦。
: 第三，很多活动比如年夜饭都是很早就订好的。所以买票人必须实时知道票买到了没有
: 。如果拖到第二天才知道那可能整个行程就毁了。而且不实时的系统容易被怀疑有人为
: 做手脚。
| B****D
发帖数: 132 | 6 想简单了. 你如果在AMAZON做过, 就明白BUNDLE做起来是很不一样的.
举个例子. 两班车, 都从A->B->C->D. 顾客有要求A->B的. 有要求C->D的. 也有A->C的
, B->D的. 如果最大满足, 是个优化问题.
即使最后你剩了第一班车的 A->B, 第二班车的B->C. 如果来个顾客要A->C, 你让他中
间在B换车, 他愿意么?
【在 g*****g 的大作中提到】
: 优化啥呀，每天1000趟车，一趟车3种座位，20个区段，就当作6万种商品，每种商品有
: 个计数器。
: 下单就是把所有的跑的段－1。 RDBMS transaction保证integrity, 前面都算过，每天
: 放票10次，每次
: 最多4分钟也处理完了。
| g*****g
发帖数: 34805 | 7 没啥不合理的，先来后到而已，你也可以预设多少张票必须从某个站始发，多少张票必
须跑全程之类的，这个无非就
是细分商品种类而已，游戏规则是开发者定的。
我刚才说的商品数目只有几万种，你细分100倍，到几百万种也不多。数据库的性能主
要是由交易数目和锁row conflict多少决定的，你分的越细，conflict越少，性能反而
提高。
【在 B****D 的大作中提到】
: 想简单了. 你如果在AMAZON做过, 就明白BUNDLE做起来是很不一样的.
: 举个例子. 两班车, 都从A->B->C->D. 顾客有要求A->B的. 有要求C->D的. 也有A->C的
: , B->D的. 如果最大满足, 是个优化问题.
: 即使最后你剩了第一班车的 A->B, 第二班车的B->C. 如果来个顾客要A->C, 你让他中
: 间在B换车, 他愿意么?
| B****D
发帖数: 132 | 8 为什么一定要加锁呢? 不加, 性能才最佳.
【在 g*****g 的大作中提到】
: 没啥不合理的，先来后到而已，你也可以预设多少张票必须从某个站始发，多少张票必
: 须跑全程之类的，这个无非就
: 是细分商品种类而已，游戏规则是开发者定的。
: 我刚才说的商品数目只有几万种，你细分100倍，到几百万种也不多。数据库的性能主
: 要是由交易数目和锁row conflict多少决定的，你分的越细，conflict越少，性能反而
: 提高。
| g*****g
发帖数: 34805 | 9 不锁就不能保证integrity, 票可以重卖少卖。
【在 B****D 的大作中提到】
: 为什么一定要加锁呢? 不加, 性能才最佳.
| L******f
发帖数: 5368 | 10 可以不加锁，但是数据库必须自己开发。
用shared memory。几百个数据库
机器共享。Integrity Check由
每个机器自己做，在share memory
上写的时候，只锁要写得部分。
这样，几百个机器就可以同步
实时更新数据库。
这里有一个问题。万一死机的话，
shared memory就要全部丢失。
为了解决这个问题，必须有一个
master machine, 不停地
把shared memory写到硬盘。
万一死机，把master machine
上硬盘数据恢复到shared memory.
【在 g*****g 的大作中提到】
: 不锁就不能保证integrity, 票可以重卖少卖。
| | | g*****g
发帖数: 34805 | 11 有成熟方案，非要自己做轮子的，项目基本以失败结束。
【在 L******f 的大作中提到】
: 可以不加锁，但是数据库必须自己开发。
: 用shared memory。几百个数据库
: 机器共享。Integrity Check由
: 每个机器自己做，在share memory
: 上写的时候，只锁要写得部分。
: 这样，几百个机器就可以同步
: 实时更新数据库。
: 这里有一个问题。万一死机的话，
: shared memory就要全部丢失。
: 为了解决这个问题，必须有一个
| s******a
发帖数: 527 | 12 我觉得12306刚出的时候就是用你这样的方案，然后发现，抢票的时候所有人的页面就
是等几分钟没响应，终于有响应的时候告诉你没票。于是纷纷上网狂骂。。。
【在 g*****g 的大作中提到】
: 优化啥呀，每天1000趟车，一趟车3种座位，20个区段，就当作6万种商品，每种商品有
: 个计数器。
: 下单就是把所有的跑的段－1。 RDBMS transaction保证integrity, 前面都算过，每天
: 放票10次，每次
: 最多4分钟也处理完了。
| k**i
发帖数: 10191 | 13 如果你是对的，这个脸打的厉害。关键是半桶水响叮当，做这个项目的人和公司经验知
识储备都不够。
【在 s******a 的大作中提到】
: 我觉得12306刚出的时候就是用你这样的方案，然后发现，抢票的时候所有人的页面就
: 是等几分钟没响应，终于有响应的时候告诉你没票。于是纷纷上网狂骂。。。
| N********d
发帖数: 298 | 14 你这个第二天出票会被活活骂死，所有没拿到票的人都会说这一晚上是暗箱操作的时间
【在 B****D 的大作中提到】
: 先声明, 不清楚目前系统的问题. 只看了两眼讨论.
: 我觉得, 从THINK OUT OF BOX 角度来说, 火车订票不一定需要跟飞机定票一样的下单
: 出票. 做几个假设.
: 1. 假设运力小于需求量.
: 在这个前提下, 火车出票还需要做到尽可能地把每辆车塞满. 因此, 它还是个座位优化
: 问题. 我坐高铁注意到这个问题. 起发站坐满了. 中间人下去了, 很长时间内空着, 到
: 了个大站又上满了.
: 2. 火车可以有一定数量的站票. 这跟飞机不一样. 事实上, 飞机定票在高峰期一般也
: 是略微过订的, 否则也不会有在机场喇叭广播谁愿意晚一班, 白给200元的事情了.
: 3. 春运的人, 一般时间上有弹性. 早一天, 晚一天, 只要不过了大年三十, 很多人不
| g*****g
发帖数: 34805 | 15 为啥会几分钟没响应，当然是立刻响应跟你说会发短信邮件通知结果。还给个确认号。
你看都现在的现象就是都排着呢，没等排到处理，timeout了。不懂瞎说的还挺多。
【在 s******a 的大作中提到】
: 我觉得12306刚出的时候就是用你这样的方案，然后发现，抢票的时候所有人的页面就
: 是等几分钟没响应，终于有响应的时候告诉你没票。于是纷纷上网狂骂。。。
| w*********m
发帖数: 4740 | 16 先来后到就是greedy algo, 不是最大化整体运力
交通学科了已经用博弈论研究过这类问题几十年了
cs某年acm最佳phd disertation搞self routing就是从交通工程里借用了其idea
【在 g*****g 的大作中提到】
: 没啥不合理的，先来后到而已，你也可以预设多少张票必须从某个站始发，多少张票必
: 须跑全程之类的，这个无非就
: 是细分商品种类而已，游戏规则是开发者定的。
: 我刚才说的商品数目只有几万种，你细分100倍，到几百万种也不多。数据库的性能主
: 要是由交易数目和锁row conflict多少决定的，你分的越细，conflict越少，性能反而
: 提高。
| g*****g
发帖数: 34805 | 17 优化可以有，比如按照历史数据各站预留票，这样不会中间站的上不了，一直都是这么
做的。
但公平才是最重要的，反正热门票怎么都是卖光。
【在 w*********m 的大作中提到】
: 先来后到就是greedy algo, 不是最大化整体运力
: 交通学科了已经用博弈论研究过这类问题几十年了
: cs某年acm最佳phd disertation搞self routing就是从交通工程里借用了其idea
| l*****9
发帖数: 9501 | 18 全程票历来是优先的，但是中间客站也会留些票。网上订票一大好处是计划临客，如果
有waiting list的话，可惜做12306的技术团队比较废物
【在 g*****g 的大作中提到】
: 优化可以有，比如按照历史数据各站预留票，这样不会中间站的上不了，一直都是这么
: 做的。
: 但公平才是最重要的，反正热门票怎么都是卖光。
| p********5
发帖数: 49 | 19 僧多粥少一直是国内资源和运力的诟病。除了人口总数下降，或者年青一代努力改变。
其实大家也习惯了这种环境，有时候想想日本人这些方面做得很好，日本人口密度不比
中国小。车站，住房更加拥挤。但是一直有一种好的秩序。
还是要把争抢的风气逐渐淡化，社会资源才能更好的分配。 | b*****g
发帖数: 2322 | 20 其实系统应该跟Kayak，或者expedia学习，这跟回国买飞机票差不多，早定比晚定便宜
，立刻走你想要得班次就要天价，转乘要比直达便宜。
系统根据库存情况自动optimize价格。 | m**********j
发帖数: 8645 | 21 这话说的真烂。
春运买票回家，买到了就能回，买不到就回不了。
跟你去年回国似的。你假请好了，就是买不到票，或者比你计划要晚半个月才有票。
【在 p********5 的大作中提到】
: 僧多粥少一直是国内资源和运力的诟病。除了人口总数下降，或者年青一代努力改变。
: 其实大家也习惯了这种环境，有时候想想日本人这些方面做得很好，日本人口密度不比
: 中国小。车站，住房更加拥挤。但是一直有一种好的秩序。
: 还是要把争抢的风气逐渐淡化，社会资源才能更好的分配。
| m**********j
发帖数: 8645 | 22 kayak或者expedia面对过几千万人要在同一天南北大搬家吗?
【在 b*****g 的大作中提到】
: 其实系统应该跟Kayak，或者expedia学习，这跟回国买飞机票差不多，早定比晚定便宜
: ，立刻走你想要得班次就要天价，转乘要比直达便宜。
: 系统根据库存情况自动optimize价格。
|
|
