由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Programming版 - 看了看程序员们的12306方案,真不值配他们那么多钱。
相关主题
从12306来看,国内IT水平不高魏公公,赌局我接了,你把500万/秒的订票系统做出来
老魏号称100%出票,现在的算法有碎片化问题吧。古德霸放个带细节设计的方案吧
有人看懂赵老师的 100% 出票什么概念没有?12306仍然一塌糊涂
100%和必需出票属于没戏了继续,好虫这个赌约我接了
出票正确率的定义,赵,姜请进。还有一个问题
魏老师的方案请问一个基本的minimization problem有没有近似解法? (转载)
在讨论12306前算法求教
古德霸啊古德霸,不打你脸是不行了大家帮我回忆一下,以前在这里遇见的一个题目
相关话题的讨论汇总
话题: 撮合话题: 高大话题: 方案话题: 抽签话题: 12306
进入Programming版参与讨论
1 (共1页)
s****u
发帖数: 1433
1
面对任何一个问题,都是需要高大上进行战略布局,然后
分解给程序员们实现。程序员们是解决不了高大上问题的。
12306的本质是有限资源合理分配的问题。当程序员还在分析
要求1秒钟实现多少TRANSACTION的问题,高大上会告诉他们,
这根本不是他们需要考虑的。
因为,这根本就是个伪命题。
真正的问题是:根据时间抢票是不是社会最优方案?
什么是社会最优,就是根据有限资源满足社会需求的最佳配置方案。
什么是最优?最小成本办最多的事。
这等同于让手最快的人优先抢到票么?显然不是。
妙杀抢票法,不过是吊丝们有限的智慧短时间找到的一个貌似公平的
方案而已。
高大上要问问吊丝们:你们打过新股没有?这跟定票难道不是同样的问题么?
知道什么是集合竞价么,知道什么是自动撮合么?
一个可以非常简单地化解的瓶颈非要用秒杀的土法子解决,吊丝们惭愧不?
12306完全可以采用时间段预先登记,等固定时间自动撮合出票的办法,
彻底摆脱秒杀法和机器人票贩子,OCR等等垃圾。撮合有足够的时间,所谓
服务器的IO瓶颈烟消雾散。
当然,撮合的策略和算法,高大上就留给吊丝码工去考虑吧。
w*********m
发帖数: 4740
2
从整体利益来讲这样最好

【在 s****u 的大作中提到】
: 面对任何一个问题,都是需要高大上进行战略布局,然后
: 分解给程序员们实现。程序员们是解决不了高大上问题的。
: 12306的本质是有限资源合理分配的问题。当程序员还在分析
: 要求1秒钟实现多少TRANSACTION的问题,高大上会告诉他们,
: 这根本不是他们需要考虑的。
: 因为,这根本就是个伪命题。
: 真正的问题是:根据时间抢票是不是社会最优方案?
: 什么是社会最优,就是根据有限资源满足社会需求的最佳配置方案。
: 什么是最优?最小成本办最多的事。
: 这等同于让手最快的人优先抢到票么?显然不是。

l*****9
发帖数: 9501
3
devil is in the details,讲讲具体怎样 “采用时间段预先登记,等固定时间自动撮
合出票”
w*********m
发帖数: 4740
4
就是写下需求,这样不需要考虑同步,最后再批处理,或者另外线程单个处理

【在 l*****9 的大作中提到】
: devil is in the details,讲讲具体怎样 “采用时间段预先登记,等固定时间自动撮
: 合出票”

l*****9
发帖数: 9501
5
我们建议的就是先接下订单,然后后台批量处理。同样概念换个非人类语言,就高大上
了?

【在 w*********m 的大作中提到】
: 就是写下需求,这样不需要考虑同步,最后再批处理,或者另外线程单个处理
g*****g
发帖数: 34805
6
人多票少,预先登记怎么算公平,不还是一样得有个排队的办法。来个预登记票就能多
出来?搞笑吧。
w*********m
发帖数: 4740
7
我就是说是一个意思

【在 l*****9 的大作中提到】
: 我们建议的就是先接下订单,然后后台批量处理。同样概念换个非人类语言,就高大上
: 了?

a***y
发帖数: 852
8
拜服了
a***y
发帖数: 852
9
拜服了
s******8
发帖数: 4192
10
终于有人说到点子上了。允许一个人每10分钟下个order,然后后台每十分钟集中撮合
一次(供小于求就抽签)。负载太重,间隔调上去就成,20分钟,半小时,一个小时一
次都行。负载立刻下来。

【在 s****u 的大作中提到】
: 面对任何一个问题,都是需要高大上进行战略布局,然后
: 分解给程序员们实现。程序员们是解决不了高大上问题的。
: 12306的本质是有限资源合理分配的问题。当程序员还在分析
: 要求1秒钟实现多少TRANSACTION的问题,高大上会告诉他们,
: 这根本不是他们需要考虑的。
: 因为,这根本就是个伪命题。
: 真正的问题是:根据时间抢票是不是社会最优方案?
: 什么是社会最优,就是根据有限资源满足社会需求的最佳配置方案。
: 什么是最优?最小成本办最多的事。
: 这等同于让手最快的人优先抢到票么?显然不是。

相关主题
魏老师的方案魏公公,赌局我接了,你把500万/秒的订票系统做出来
在讨论12306前古德霸放个带细节设计的方案吧
古德霸啊古德霸,不打你脸是不行了12306仍然一塌糊涂
进入Programming版参与讨论
m**********j
发帖数: 8645
11
你明显就没买过春运的火车票。

【在 s******8 的大作中提到】
: 终于有人说到点子上了。允许一个人每10分钟下个order,然后后台每十分钟集中撮合
: 一次(供小于求就抽签)。负载太重,间隔调上去就成,20分钟,半小时,一个小时一
: 次都行。负载立刻下来。

s***o
发帖数: 6934
12
that's why a good product manager who really understands technology is key.

【在 s****u 的大作中提到】
: 面对任何一个问题,都是需要高大上进行战略布局,然后
: 分解给程序员们实现。程序员们是解决不了高大上问题的。
: 12306的本质是有限资源合理分配的问题。当程序员还在分析
: 要求1秒钟实现多少TRANSACTION的问题,高大上会告诉他们,
: 这根本不是他们需要考虑的。
: 因为,这根本就是个伪命题。
: 真正的问题是:根据时间抢票是不是社会最优方案?
: 什么是社会最优,就是根据有限资源满足社会需求的最佳配置方案。
: 什么是最优?最小成本办最多的事。
: 这等同于让手最快的人优先抢到票么?显然不是。

n*****t
发帖数: 22014
13
一个车次排队,过 24 小时抽签。没中的明天再来?
擦,还有比这更烂的主意吗?

【在 s****u 的大作中提到】
: 面对任何一个问题,都是需要高大上进行战略布局,然后
: 分解给程序员们实现。程序员们是解决不了高大上问题的。
: 12306的本质是有限资源合理分配的问题。当程序员还在分析
: 要求1秒钟实现多少TRANSACTION的问题,高大上会告诉他们,
: 这根本不是他们需要考虑的。
: 因为,这根本就是个伪命题。
: 真正的问题是:根据时间抢票是不是社会最优方案?
: 什么是社会最优,就是根据有限资源满足社会需求的最佳配置方案。
: 什么是最优?最小成本办最多的事。
: 这等同于让手最快的人优先抢到票么?显然不是。

m**********j
发帖数: 8645
14
虫虫就是要你把你的order发给服务器,然后坐在家里的小马扎上等短信,等到地老天
荒。

【在 n*****t 的大作中提到】
: 一个车次排队,过 24 小时抽签。没中的明天再来?
: 擦,还有比这更烂的主意吗?

n*****t
发帖数: 22014
15
买不到的就怀疑被做手脚了

【在 m**********j 的大作中提到】
: 虫虫就是要你把你的order发给服务器,然后坐在家里的小马扎上等短信,等到地老天
: 荒。

g*****g
发帖数: 34805
16
订单有时间戳,网站公布线路最后一张票出票对应时间,前面的都买找,后面的都买不
着。
不信的可以出来吐槽互相核对。没买着票总有人骂,只能做到透明度尽量高罢了。

【在 n*****t 的大作中提到】
: 买不到的就怀疑被做手脚了
b*****g
发帖数: 2322
17
同意,北京车牌为什么是摇号,而不是秒杀?
n*****t
发帖数: 22014
18
从北京到湘潭我有 12 个车次可以选择,如果时间可以浮动 3 天那就是 36 个车次,
买联程的话就再加 36 个,36x36 = 1000+ 个选择。每次抽签 10 分钟,不考虑就算排
72 次队也要 12 小时,我还不如去窗口买呢 。。。

【在 g*****g 的大作中提到】
: 订单有时间戳,网站公布线路最后一张票出票对应时间,前面的都买找,后面的都买不
: 着。
: 不信的可以出来吐槽互相核对。没买着票总有人骂,只能做到透明度尽量高罢了。

g*****g
发帖数: 34805
19
抽签可不是我提的,再说就算抽签,难道不能并行抽?非要顺序?

【在 n*****t 的大作中提到】
: 从北京到湘潭我有 12 个车次可以选择,如果时间可以浮动 3 天那就是 36 个车次,
: 买联程的话就再加 36 个,36x36 = 1000+ 个选择。每次抽签 10 分钟,不考虑就算排
: 72 次队也要 12 小时,我还不如去窗口买呢 。。。

b*******s
发帖数: 5216
20
非刚需

【在 b*****g 的大作中提到】
: 同意,北京车牌为什么是摇号,而不是秒杀?
相关主题
继续,好虫这个赌约我接了算法求教
还有一个问题大家帮我回忆一下,以前在这里遇见的一个题目
请问一个基本的minimization problem有没有近似解法? (转载)定义的struct数组很大时,为什么会出现奇怪的大数字?
进入Programming版参与讨论
n*****t
发帖数: 22014
21
并行抽肯定不行啊 。。。我 72 个队全排上,先不说有多麻烦,抽完我中了 10 签,
结果只要 2 张票,其余 8 张还得扔回去重抽,关联影响到 80 张票的重新排队

【在 g*****g 的大作中提到】
: 抽签可不是我提的,再说就算抽签,难道不能并行抽?非要顺序?
b*******s
发帖数: 5216
22
那个顺序排队的方案,就是基本没考虑耦合性

【在 n*****t 的大作中提到】
: 并行抽肯定不行啊 。。。我 72 个队全排上,先不说有多麻烦,抽完我中了 10 签,
: 结果只要 2 张票,其余 8 张还得扔回去重抽,关联影响到 80 张票的重新排队

g*****g
发帖数: 34805
23
抽签的时候把所有队的单子排队了,退票直接顺序来。

【在 n*****t 的大作中提到】
: 并行抽肯定不行啊 。。。我 72 个队全排上,先不说有多麻烦,抽完我中了 10 签,
: 结果只要 2 张票,其余 8 张还得扔回去重抽,关联影响到 80 张票的重新排队

n*****t
发帖数: 22014
24
退票开销非常大的,良民让你逼成黄牛了

【在 g*****g 的大作中提到】
: 抽签的时候把所有队的单子排队了,退票直接顺序来。
q*c
发帖数: 9453
25
哪里有这么多麻烦的事情, 你一次给提交你全部的可能选择, 系统给你找最靠前的一
个, 下面的就没有了!
然后你就付钱, 或者交 30% 的退票费。
这事情思路理顺了不难。主要就是不能实时, 要排队批处理。 流量黄牛一次搞定。

【在 n*****t 的大作中提到】
: 并行抽肯定不行啊 。。。我 72 个队全排上,先不说有多麻烦,抽完我中了 10 签,
: 结果只要 2 张票,其余 8 张还得扔回去重抽,关联影响到 80 张票的重新排队

q*c
发帖数: 9453
26
每个人每次只许提交一次 - 一次提交所有的队。 你要提交多次? 那就准备多缴钱呗。
match 第一个系统就 terminate
这些都是小问题。只要想, 办法无穷多。
那 real time 无法 scale out 的问题才是真问题。

【在 g*****g 的大作中提到】
: 抽签的时候把所有队的单子排队了,退票直接顺序来。
T*******h
发帖数: 112
27
确实可以考虑为什么一定要实时,平时大家在互联网上可能习惯了啥都比较实时,但是
并不代表不实时就不合理,特别是对于很多供远大于求的产品,“先到先得”是一种公
平,先报需求然后抽签,也是一种公平,后者对于供远大于求的基本产品貌似更加公平。
至于这种情况下怎么组合票回家,到时自然会有很多替代方案,也不应该因为这个非广
泛性或者进一步需求而影响基本需求的解决。
b*******s
发帖数: 5216
28
你不能让用户屈从于你的设计,教育用户的成功商业范例,也就是jobs还活着那阵子的
果子公司还能玩转,而且那些用户是没有预设期望的

平。

【在 T*******h 的大作中提到】
: 确实可以考虑为什么一定要实时,平时大家在互联网上可能习惯了啥都比较实时,但是
: 并不代表不实时就不合理,特别是对于很多供远大于求的产品,“先到先得”是一种公
: 平,先报需求然后抽签,也是一种公平,后者对于供远大于求的基本产品貌似更加公平。
: 至于这种情况下怎么组合票回家,到时自然会有很多替代方案,也不应该因为这个非广
: 泛性或者进一步需求而影响基本需求的解决。

g*****g
发帖数: 34805
29
是,前后分开就是解决这个系统的核心思想,其余的都是细节而已。

呗。

【在 q*c 的大作中提到】
: 每个人每次只许提交一次 - 一次提交所有的队。 你要提交多次? 那就准备多缴钱呗。
: match 第一个系统就 terminate
: 这些都是小问题。只要想, 办法无穷多。
: 那 real time 无法 scale out 的问题才是真问题。

g*****g
发帖数: 34805
30
现实生活排队买票就没有啥实时的,难道一到火车站就能轮到你?这下网上排个队有啥
好几歪的。

平。

【在 T*******h 的大作中提到】
: 确实可以考虑为什么一定要实时,平时大家在互联网上可能习惯了啥都比较实时,但是
: 并不代表不实时就不合理,特别是对于很多供远大于求的产品,“先到先得”是一种公
: 平,先报需求然后抽签,也是一种公平,后者对于供远大于求的基本产品貌似更加公平。
: 至于这种情况下怎么组合票回家,到时自然会有很多替代方案,也不应该因为这个非广
: 泛性或者进一步需求而影响基本需求的解决。

相关主题
0/1 Knapsack问题Linear Space的算法可以实现Backtrack吗?老魏号称100%出票,现在的算法有碎片化问题吧。
求算法有人看懂赵老师的 100% 出票什么概念没有?
从12306来看,国内IT水平不高100%和必需出票属于没戏了
进入Programming版参与讨论
s******8
发帖数: 4192
31
这有什么难解决的。这种系统不知道做过多少个的。如果有你这种需求,很简单。就是
允许下72个不同的order。你可以排列组合,下1000个都没关系。每个收一点订金。然
后你自己列出priority。系统根据你的prioirty来抽签,第一个抽不中,自动抽第二个
。抽中一个,后面的order全部作废。不过你不买,全部1000个order定金没收就行。所
以用户自己掂量。可以每十分钟下一个,也可以每十分钟下10个。

【在 n*****t 的大作中提到】
: 从北京到湘潭我有 12 个车次可以选择,如果时间可以浮动 3 天那就是 36 个车次,
: 买联程的话就再加 36 个,36x36 = 1000+ 个选择。每次抽签 10 分钟,不考虑就算排
: 72 次队也要 12 小时,我还不如去窗口买呢 。。。

n*****t
发帖数: 22014
32
本来是一天 5M 的订单来不及处理,现在变成 5G 的查询、加锁。一张火车票 300,就
算10% 押金,我同时抽 72 个就得准备 2000+

【在 s******8 的大作中提到】
: 这有什么难解决的。这种系统不知道做过多少个的。如果有你这种需求,很简单。就是
: 允许下72个不同的order。你可以排列组合,下1000个都没关系。每个收一点订金。然
: 后你自己列出priority。系统根据你的prioirty来抽签,第一个抽不中,自动抽第二个
: 。抽中一个,后面的order全部作废。不过你不买,全部1000个order定金没收就行。所
: 以用户自己掂量。可以每十分钟下一个,也可以每十分钟下10个。

p********e
发帖数: 6030
33
抽签?就像国内买彩票那样?

【在 s******8 的大作中提到】
: 终于有人说到点子上了。允许一个人每10分钟下个order,然后后台每十分钟集中撮合
: 一次(供小于求就抽签)。负载太重,间隔调上去就成,20分钟,半小时,一个小时一
: 次都行。负载立刻下来。

g*****g
发帖数: 34805
34
车次有没有票,是放在cache里的,卖完了设标志位,退票再弄回来。要是卖完了,根
本不用查询数据库就可以往下走,直到有票的车次为止。对数据库仍然是一个操作。
排队是应用服务器管的,瓶颈在数据库上。票数是固定的,数据库操作数目自然也是固
定的。只要收单能scale out, 你定多少张都不会减慢速度。

【在 n*****t 的大作中提到】
: 本来是一天 5M 的订单来不及处理,现在变成 5G 的查询、加锁。一张火车票 300,就
: 算10% 押金,我同时抽 72 个就得准备 2000+

s****u
发帖数: 1433
35
高大上再给大家提示一句:
当服务器掌握了一定时间段内的全部需求以后,
就有可能进行优化。
这里优化第一是优化当前的撮合。比如,撮合结果目标
是满座律极大化,那么就可以找到比抽签以及时间戳的
办法更好的撮合结果。这样,会有更多的人买到票回家,
铁路利润也会高。
优化第二是为了未来发展。没买到票的数据直接可以用来
决策临时客车甚至下一条铁路的建设。这不是免费的市场
数据嘛。
什么是高大上,就得比别人多看两步或者三步。
l*****9
发帖数: 9501
36
不懂编程的滚远点儿。你要觉得你能做得更好,拿出具体方案来。devil is in the
detail. 大而化之的不适合本版。
q*c
发帖数: 9453
37
你每天屈从于上帝的物理定律, 你不服气?
或者你更喜欢屈从于在死机的系统前面骂娘 10 个小时苦苦刷机? lol

【在 b*******s 的大作中提到】
: 你不能让用户屈从于你的设计,教育用户的成功商业范例,也就是jobs还活着那阵子的
: 果子公司还能玩转,而且那些用户是没有预设期望的
:
: 平。

s****u
发帖数: 1433
38
呵呵,本人学编程的时候,你估计还是液体呢。
即便是春运最高峰,仍然有火车的某些座位在某些路段遭闲置。
这些都是可以优化减少的。
高大上告诉你,这是标准的多维KNAPSACK问题。好处是可以
分线路解决,变量也有限,不会在乎NP问题。
算了,你个程序员
反正也听不懂。

【在 l*****9 的大作中提到】
: 不懂编程的滚远点儿。你要觉得你能做得更好,拿出具体方案来。devil is in the
: detail. 大而化之的不适合本版。

l*****9
发帖数: 9501
39
没有细节就是彻淡。吹牛不上税

【在 s****u 的大作中提到】
: 呵呵,本人学编程的时候,你估计还是液体呢。
: 即便是春运最高峰,仍然有火车的某些座位在某些路段遭闲置。
: 这些都是可以优化减少的。
: 高大上告诉你,这是标准的多维KNAPSACK问题。好处是可以
: 分线路解决,变量也有限,不会在乎NP问题。
: 算了,你个程序员
: 反正也听不懂。

s****u
发帖数: 1433
40
早说了,细节是吊丝们的菜。

【在 l*****9 的大作中提到】
: 没有细节就是彻淡。吹牛不上税
相关主题
100%和必需出票属于没戏了在讨论12306前
出票正确率的定义,赵,姜请进。古德霸啊古德霸,不打你脸是不行了
魏老师的方案魏公公,赌局我接了,你把500万/秒的订票系统做出来
进入Programming版参与讨论
o******o
发帖数: 458
41
春运期间,“撮合结果目标是满座律极大化”。
你的高大上,是在撮合纽约到华盛顿的车票吗?
obamacare采用的就是高大上方案 :)

【在 s****u 的大作中提到】
: 高大上再给大家提示一句:
: 当服务器掌握了一定时间段内的全部需求以后,
: 就有可能进行优化。
: 这里优化第一是优化当前的撮合。比如,撮合结果目标
: 是满座律极大化,那么就可以找到比抽签以及时间戳的
: 办法更好的撮合结果。这样,会有更多的人买到票回家,
: 铁路利润也会高。
: 优化第二是为了未来发展。没买到票的数据直接可以用来
: 决策临时客车甚至下一条铁路的建设。这不是免费的市场
: 数据嘛。

s******8
发帖数: 4192
42
供小于求的情况只能抽签,否则对绝大多数人都不公平。抽签时最公平的。把硬件,环
境和人的影响降到最低。

【在 p********e 的大作中提到】
: 抽签?就像国内买彩票那样?
s****u
发帖数: 1433
43
很好。有同学注意到了,抽签是相对公平的手段。
显然,这比允许黄牛跑机器人,雇民工排队,内部票后门要公平。
但是,这真是最公平的手段么?
特想回家的和一般想回家的,应该得到同样的买票概率么?
排队一宿的人和早上才来的人,应该同样概率买到高大上的演唱会的票么?
这些都是需要考虑的问题。
d*****r
发帖数: 9
44
铁道部要的本来就是时效 这还要和窗口订票 电话订票结合起来
不是你简单的说网上订票排队 固定时间抽一次签就行的
那样的话是不是在窗口排了一晚上排到后售票员也要告诉你要参加抽签 系统的余票查
询也完全不准确
那样的系统不被骂死才怪 对于这个问题抛去时效的解决方案都是伪方案
f****n
发帖数: 208
45
为什么不可以象飞机票一样,每张票上印有名字,证件号, 只能本人乘坐。网上提前更
长时间允许购买(比如半年),对于需求量大的票根据销售进行价格浮动。同时预留20
%-30%的票,只允许在窗口销售。(比如提前7天,网上的70%-80%的票应该已经卖完。
l*****9
发帖数: 9501
46

已经这样了
政治压力太大
why not 100% online? Online is better, and easier to get rid of 黄牛
现在12306做得很烂,成了黄牛的天堂

【在 f****n 的大作中提到】
: 为什么不可以象飞机票一样,每张票上印有名字,证件号, 只能本人乘坐。网上提前更
: 长时间允许购买(比如半年),对于需求量大的票根据销售进行价格浮动。同时预留20
: %-30%的票,只允许在窗口销售。(比如提前7天,网上的70%-80%的票应该已经卖完。
: )

m**********j
发帖数: 8645
47
不说别的,你下次回国坐一次火车就知道了。
在窗口或者自动售卖机前是用身份证购票。二代证必须被读一次。

20

【在 f****n 的大作中提到】
: 为什么不可以象飞机票一样,每张票上印有名字,证件号, 只能本人乘坐。网上提前更
: 长时间允许购买(比如半年),对于需求量大的票根据销售进行价格浮动。同时预留20
: %-30%的票,只允许在窗口销售。(比如提前7天,网上的70%-80%的票应该已经卖完。
: )

f****n
发帖数: 208
48
不全部online是为了防止有些票网上卖的太快,留出一部分在发车前几天再卖,只能窗
口排队购买,这部分票每张票有名字且不允许退。

【在 l*****9 的大作中提到】
:
: 已经这样了
: 政治压力太大
: why not 100% online? Online is better, and easier to get rid of 黄牛
: 现在12306做得很烂,成了黄牛的天堂

f****n
发帖数: 208
49
你是说问题是没有人核对名字所以黄牛才可以倒票?

【在 m**********j 的大作中提到】
: 不说别的,你下次回国坐一次火车就知道了。
: 在窗口或者自动售卖机前是用身份证购票。二代证必须被读一次。
:
: 20

l*****9
发帖数: 9501
50
票卖的快is good

【在 f****n 的大作中提到】
: 不全部online是为了防止有些票网上卖的太快,留出一部分在发车前几天再卖,只能窗
: 口排队购买,这部分票每张票有名字且不允许退。

相关主题
古德霸放个带细节设计的方案吧还有一个问题
12306仍然一塌糊涂请问一个基本的minimization problem有没有近似解法? (转载)
继续,好虫这个赌约我接了算法求教
进入Programming版参与讨论
s****u
发帖数: 1433
51
所有的人都有误区。
比如有人问:为什么不都网售?
不会上网的民工哭了。
为什么不全部提前定票?
放假时间不固定的吊丝哭了。
为什么不允许用价格调控?
铁道部哭了。
f****n
发帖数: 208
52
供小于求的问题,要公平,只能用价格和时间优先来解决。为照顾无法上网的人群,必
须预留窗口票在几天前开始发售(网售之后几个月),甚至为了公平可以同时关闭网上
售票。价格上作浮动,提早网上售票开始时间和监控(查IP,信用卡号,证件号。。。)

【在 s****u 的大作中提到】
: 所有的人都有误区。
: 比如有人问:为什么不都网售?
: 不会上网的民工哭了。
: 为什么不全部提前定票?
: 放假时间不固定的吊丝哭了。
: 为什么不允许用价格调控?
: 铁道部哭了。

l*****9
发帖数: 9501
53
铁道部指定售票点手续费最高5元,不会上网的民工出5元省了排几天队

。)

【在 f****n 的大作中提到】
: 供小于求的问题,要公平,只能用价格和时间优先来解决。为照顾无法上网的人群,必
: 须预留窗口票在几天前开始发售(网售之后几个月),甚至为了公平可以同时关闭网上
: 售票。价格上作浮动,提早网上售票开始时间和监控(查IP,信用卡号,证件号。。。)

1 (共1页)
进入Programming版参与讨论
相关主题
大家帮我回忆一下,以前在这里遇见的一个题目出票正确率的定义,赵,姜请进。
定义的struct数组很大时,为什么会出现奇怪的大数字?魏老师的方案
0/1 Knapsack问题Linear Space的算法可以实现Backtrack吗?在讨论12306前
求算法古德霸啊古德霸,不打你脸是不行了
从12306来看,国内IT水平不高魏公公,赌局我接了,你把500万/秒的订票系统做出来
老魏号称100%出票,现在的算法有碎片化问题吧。古德霸放个带细节设计的方案吧
有人看懂赵老师的 100% 出票什么概念没有?12306仍然一塌糊涂
100%和必需出票属于没戏了继续,好虫这个赌约我接了
相关话题的讨论汇总
话题: 撮合话题: 高大话题: 方案话题: 抽签话题: 12306