由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Programming版 - 测试用例在此,看还有什么说的。
相关主题
操!本版连interlocked指令都没有懂的?扯两句魏老师vs好虫
goodbug又丢人了潜水员上来评价一下这几天的混战,乔峰大战鸠摩智
我来写个老魏的详细实现方案。(更新了缺点)没干过大数据云计算的不用琢磨12306了
真让老魏讨论需求时候,老魏就开始打滚了qxc,我接招了,你给的要求太弱的,给你加强了
做presentation要简单明了阿搞技术的,要有起码的是非观念 by 老魏
哥决定常驻这个版了其实就是两党党争
zz 12306是怎样做成的赌约在此
从12306来看,国内IT水平不高简单介绍一下老魏的结构
相关话题的讨论汇总
话题: 问题话题: 车次话题: decrement话题: 测试用例话题: 保证
进入Programming版参与讨论
1 (共1页)
g*****g
发帖数: 34805
1
跟你说了decrement再increment不是原子操作,你真是连基础知识都没有。
假如现在就剩一张票a->b, 来了两个单子a->b->c 和 a->b.
DB transaction保证了无论以任何顺序执行,a->b得票都能卖出去。
decrement再increment得做法,当单子同时到得时候,就有可能产生这样得执行顺序。
decrementAndGet(a->b) = 0, decrementAndGet(a->b) = -1
decrementAndGet(b->c) = -1.
结果就是票子没卖出去。
卖票得原则大家都很清楚,不许错票重票,不许有票不出。这个case可能最终导致好好
的票子卖不掉,正确性都不能保证,还谈个屁性能。没有正确性的高性能没有意义。
那几个捧臭脚的好好反思吧,到底谁是半瓶醋。
至于魏公公,不能把这个测试用例驳倒,就永远做太监吧。
n*****t
发帖数: 22014
2
第一,我不 care 这种情况,买不到的人会不断刷屏,早晚卖出去
第二,如果一定要处理,我把 abc 设为一个虚拟车次

【在 g*****g 的大作中提到】
: 跟你说了decrement再increment不是原子操作,你真是连基础知识都没有。
: 假如现在就剩一张票a->b, 来了两个单子a->b->c 和 a->b.
: DB transaction保证了无论以任何顺序执行,a->b得票都能卖出去。
: decrement再increment得做法,当单子同时到得时候,就有可能产生这样得执行顺序。
: decrementAndGet(a->b) = 0, decrementAndGet(a->b) = -1
: decrementAndGet(b->c) = -1.
: 结果就是票子没卖出去。
: 卖票得原则大家都很清楚,不许错票重票,不许有票不出。这个case可能最终导致好好
: 的票子卖不掉,正确性都不能保证,还谈个屁性能。没有正确性的高性能没有意义。
: 那几个捧臭脚的好好反思吧,到底谁是半瓶醋。

x****u
发帖数: 44466
3
商业系统必须care这种问题。

【在 n*****t 的大作中提到】
: 第一,我不 care 这种情况,买不到的人会不断刷屏,早晚卖出去
: 第二,如果一定要处理,我把 abc 设为一个虚拟车次

g*****g
发帖数: 34805
4
谁保证后面还会来单子?正确性不是靠运气保证的。一个test case fail了,也不用谈
什么性能。
我前面的前提写的很清楚,不能错票重票漏票。前提保证不了,就别出来叫板了。
至于什么虚拟车次,你最好全套写出来,再看看性能还能保证不。

【在 n*****t 的大作中提到】
: 第一,我不 care 这种情况,买不到的人会不断刷屏,早晚卖出去
: 第二,如果一定要处理,我把 abc 设为一个虚拟车次

z****e
发帖数: 54598
5
也就是无法实现公平这种原则了?
出现最坏的一种情况
同一车次,比如只有N张票
如果N+2个人同时争抢
那么就有可能出现所有人都拿不到票的情况
如果如此循环,可能在一段时间内,一张票都出不去
当然这是理想极端错误的情况的假设
但是如果N趋近于无穷大的时候
这个假设几乎一定成立

【在 n*****t 的大作中提到】
: 第一,我不 care 这种情况,买不到的人会不断刷屏,早晚卖出去
: 第二,如果一定要处理,我把 abc 设为一个虚拟车次

g*****g
发帖数: 34805
6
神仙都没办法的,可以compromise,这一个简单db transaction就能保证的。就为了魏
公公不做太监就可以放过?

【在 x****u 的大作中提到】
: 商业系统必须care这种问题。
n*****t
发帖数: 22014
7
虚拟车次还要我写出来?我以为点一下就行了 。。。

【在 g*****g 的大作中提到】
: 谁保证后面还会来单子?正确性不是靠运气保证的。一个test case fail了,也不用谈
: 什么性能。
: 我前面的前提写的很清楚,不能错票重票漏票。前提保证不了,就别出来叫板了。
: 至于什么虚拟车次,你最好全套写出来,再看看性能还能保证不。

L*****e
发帖数: 8347
8
刚才有人说了,老魏的方案是保证不重票,不保证有票不出。。。有票不出就反复刷。
。。
你们俩真是各说各的。。。

★ 发自iPhone App: ChineseWeb 8.2.2

【在 g*****g 的大作中提到】
: 跟你说了decrement再increment不是原子操作,你真是连基础知识都没有。
: 假如现在就剩一张票a->b, 来了两个单子a->b->c 和 a->b.
: DB transaction保证了无论以任何顺序执行,a->b得票都能卖出去。
: decrement再increment得做法,当单子同时到得时候,就有可能产生这样得执行顺序。
: decrementAndGet(a->b) = 0, decrementAndGet(a->b) = -1
: decrementAndGet(b->c) = -1.
: 结果就是票子没卖出去。
: 卖票得原则大家都很清楚,不许错票重票,不许有票不出。这个case可能最终导致好好
: 的票子卖不掉,正确性都不能保证,还谈个屁性能。没有正确性的高性能没有意义。
: 那几个捧臭脚的好好反思吧,到底谁是半瓶醋。

n*****t
发帖数: 22014
9
没那么严重,前面大部分人都能拿到票,临界的会争夺。而且这个 N 没么大,一个车
次一个等级的才冲突

【在 z****e 的大作中提到】
: 也就是无法实现公平这种原则了?
: 出现最坏的一种情况
: 同一车次,比如只有N张票
: 如果N+2个人同时争抢
: 那么就有可能出现所有人都拿不到票的情况
: 如果如此循环,可能在一段时间内,一张票都出不去
: 当然这是理想极端错误的情况的假设
: 但是如果N趋近于无穷大的时候
: 这个假设几乎一定成立

z****g
发帖数: 75
10
还有一种办法就是前端routing的时候,sharding就好了
这货忙了半天就找出个这问题
这个细节问题,我以为这货能自己知道可以解决

【在 n*****t 的大作中提到】
: 第一,我不 care 这种情况,买不到的人会不断刷屏,早晚卖出去
: 第二,如果一定要处理,我把 abc 设为一个虚拟车次

相关主题
哥决定常驻这个版了扯两句魏老师vs好虫
zz 12306是怎样做成的潜水员上来评价一下这几天的混战,乔峰大战鸠摩智
从12306来看,国内IT水平不高没干过大数据云计算的不用琢磨12306了
进入Programming版参与讨论
z****e
发帖数: 54598
11
当N+1个人同时争抢时候就临界了
这个N当然会很大,别忘了,天朝是运力不足哦

【在 n*****t 的大作中提到】
: 没那么严重,前面大部分人都能拿到票,临界的会争夺。而且这个 N 没么大,一个车
: 次一个等级的才冲突

x****u
发帖数: 44466
12
这还没谈到很多更实际的问题呢。
比方说领导可能需要随时调整售票策略。就算需求量再大,也不可能把所有京沪高铁车
票都卖给南京到徐州。但是如果两地间临时有重要事情发生,也许就会在特定日期内允
许此操作。

【在 g*****g 的大作中提到】
: 神仙都没办法的,可以compromise,这一个简单db transaction就能保证的。就为了魏
: 公公不做太监就可以放过?

n*****t
发帖数: 22014
13
其实就算真没票了,热情网友还得不停刷,早卖晚卖对铁老大意义不大,还怕你跑了不
成?

【在 L*****e 的大作中提到】
: 刚才有人说了,老魏的方案是保证不重票,不保证有票不出。。。有票不出就反复刷。
: 。。
: 你们俩真是各说各的。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2

z****e
发帖数: 54598
14
让ROUTING去做这种逻辑貌似就有问题
你给ZKSS
既然你喜欢探究细节的人,那我就问问你这个怎么做的
好吧,我没有PA过你,这个你可以放心说

【在 z****g 的大作中提到】
: 还有一种办法就是前端routing的时候,sharding就好了
: 这货忙了半天就找出个这问题
: 这个细节问题,我以为这货能自己知道可以解决

z****e
发帖数: 54598
15
给你一个数据
天朝春运,铁路总共就是3亿人次不到
而总共出行人次达到36亿
所以这是18倍以上的差距
那么一种极端假设
当座位数是N的时候
18N个人同时抢,会不会出现我说的问题?
很有可能

【在 n*****t 的大作中提到】
: 其实就算真没票了,热情网友还得不停刷,早卖晚卖对铁老大意义不大,还怕你跑了不
: 成?

n*****t
发帖数: 22014
16
大哥,大部分旅客是不转车的,真转车的也是先整到一张再说,还非得靠窗对面是美女
才下单啊?

【在 z****e 的大作中提到】
: 当N+1个人同时争抢时候就临界了
: 这个N当然会很大,别忘了,天朝是运力不足哦

z****e
发帖数: 54598
17
我没有说转车,就一条线的情况就行

【在 n*****t 的大作中提到】
: 大哥,大部分旅客是不转车的,真转车的也是先整到一张再说,还非得靠窗对面是美女
: 才下单啊?

n*****t
发帖数: 22014
18
你非得这么干我也没辙,那就 share code,把常见转车路线做成虚拟车,这个有大量
出票记录可以 build

【在 z****e 的大作中提到】
: 给你一个数据
: 天朝春运,铁路总共就是3亿人次不到
: 而总共出行人次达到36亿
: 所以这是18倍以上的差距
: 那么一种极端假设
: 当座位数是N的时候
: 18N个人同时抢,会不会出现我说的问题?
: 很有可能

n*****t
发帖数: 22014
19
一条线的神马问题?你刚才的帖子没看?

【在 z****e 的大作中提到】
: 我没有说转车,就一条线的情况就行
z****e
发帖数: 54598
20
行了,理论上致命的缺陷
当然zhuang说可以routing,sharding
那这个我不知道到底怎么回事
让zhuang来说

【在 n*****t 的大作中提到】
: 你非得这么干我也没辙,那就 share code,把常见转车路线做成虚拟车,这个有大量
: 出票记录可以 build

相关主题
qxc,我接招了,你给的要求太弱的,给你加强了赌约在此
搞技术的,要有起码的是非观念 by 老魏简单介绍一下老魏的结构
其实就是两党党争静态计数器和订票系统的区别
进入Programming版参与讨论
z****e
发帖数: 54598
21
我说的就是楼主说的问题啊
根转车有什么关系啊?
你说是北京-济南,济南-上海么?

【在 n*****t 的大作中提到】
: 一条线的神马问题?你刚才的帖子没看?
z****g
发帖数: 75
22
总有前端web 服务器吧,在这里把这种请求送到同个NIC,然后这个NIC上就一个thread
,然后就序列化了
当然,我认为实际实现是不必这么做的,重新刷以下就好了

【在 z****e 的大作中提到】
: 让ROUTING去做这种逻辑貌似就有问题
: 你给ZKSS
: 既然你喜欢探究细节的人,那我就问问你这个怎么做的
: 好吧,我没有PA过你,这个你可以放心说

n*****t
发帖数: 22014
23
你说的跟古德八是两个问题 。。。。你俩先掐一掐

【在 z****e 的大作中提到】
: 我说的就是楼主说的问题啊
: 根转车有什么关系啊?
: 你说是北京-济南,济南-上海么?

z****e
发帖数: 54598
24
也就是在前端做一个汇总,然后排列,然后再依次送到它那台机器上去了?
我这么理解没错吧?
那这个理论上有异步的嫌疑,我更喜欢1989那个孩子说的方案
也就无法实现REALTIME了

thread

【在 z****g 的大作中提到】
: 总有前端web 服务器吧,在这里把这种请求送到同个NIC,然后这个NIC上就一个thread
: ,然后就序列化了
: 当然,我认为实际实现是不必这么做的,重新刷以下就好了

b*******s
发帖数: 5216
25
不用原子加和减就用comp & swap咯,也是原子性的
非0就是被占了,直接失败
伪代码如下
int compare_and_swap (int* reg, int oldval, int newval)
{
ATOMIC();
int old_reg_val = *reg;
if (old_reg_val == oldval)
*reg = newval;
END_ATOMIC();
return old_reg_val;
}

【在 g*****g 的大作中提到】
: 跟你说了decrement再increment不是原子操作,你真是连基础知识都没有。
: 假如现在就剩一张票a->b, 来了两个单子a->b->c 和 a->b.
: DB transaction保证了无论以任何顺序执行,a->b得票都能卖出去。
: decrement再increment得做法,当单子同时到得时候,就有可能产生这样得执行顺序。
: decrementAndGet(a->b) = 0, decrementAndGet(a->b) = -1
: decrementAndGet(b->c) = -1.
: 结果就是票子没卖出去。
: 卖票得原则大家都很清楚,不许错票重票,不许有票不出。这个case可能最终导致好好
: 的票子卖不掉,正确性都不能保证,还谈个屁性能。没有正确性的高性能没有意义。
: 那几个捧臭脚的好好反思吧,到底谁是半瓶醋。

z****e
发帖数: 54598
26
没有啊,我跟你讨论的就是古德霸说的
济南那个是左眼说的

【在 n*****t 的大作中提到】
: 你说的跟古德八是两个问题 。。。。你俩先掐一掐
S*A
发帖数: 7142
27
这个问题我有一个不是很严格的解法,大家看看可不可以行得通。
之所以出现这种情况,是因为抢票得计数器不是严格递减的。
这样可以再引入另外一组计数器 B,在 commit 出票以后 atomic dec。
原来可递减可增加的叫计数器 A。
1: 然后抢票的时候,先看递减计数器 B,如果 《 0, 推出不用抢了。
2: 如果 》=0, 抢票,用A数组抢票。
3: 如果每个票段 抢票结果 A 》 0, 出票, B --
4: 如果《0, A++;到1:处循环。
这样似乎可以避免有票出不了的情况。
大家请拍砖头。
g*****g
发帖数: 34805
28
操,你早干嘛去了。我说用comp&swap, 你跟魏太监可是拼命嘲笑我。现在知道自己傻
逼了?半瓶醋下回别跟我现了。

【在 b*******s 的大作中提到】
: 不用原子加和减就用comp & swap咯,也是原子性的
: 非0就是被占了,直接失败
: 伪代码如下
: int compare_and_swap (int* reg, int oldval, int newval)
: {
: ATOMIC();
: int old_reg_val = *reg;
: if (old_reg_val == oldval)
: *reg = newval;
: END_ATOMIC();

n*****t
发帖数: 22014
29
古德八是 abc vs ab,ab 和 bc 是 2 个车次

【在 z****e 的大作中提到】
: 没有啊,我跟你讨论的就是古德霸说的
: 济南那个是左眼说的

T********i
发帖数: 2416
30
没啥了不起的。相当于某人reserve一张票,2us以后退掉了。
谁让你的线程比人家慢几纳秒呢?运气不好你悲愤啥?
18倍的人抢票,1趟车放票可以在毫秒级抢完。剩下几张,而且不会超过10张,因为只
有10个线程。有几毫秒震荡,问题大么?
几毫秒抢完,和几秒抢完,用户体验有区别么?
这么多人抢票,几秒内出结果,没有挤压踩踏,人身伤亡,已经是和谐社会了?
你要分析处理器电路量子效应寻求绝对公平么?

【在 z****e 的大作中提到】
: 我没有说转车,就一条线的情况就行
相关主题
请老魏给出一个简单的文字解释goodbug又丢人了
这么多讨论的,你们用过12306吗?我来写个老魏的详细实现方案。(更新了缺点)
操!本版连interlocked指令都没有懂的?真让老魏讨论需求时候,老魏就开始打滚了
进入Programming版参与讨论
a***n
发帖数: 538
31
这个可以自动重试吧,只要加个随机的延时就可以。这样的conflict本来就是时差是小
于1ms了,随机一下也谈不上损害公平性的问题吧。
d***a
发帖数: 13752
32
还在争啊...
其实两人说的spec不一样。第一个不同,应该是系统还是用户决定联票。第二个不同,
能不能有一定的概率在可出票的情况下不出票。spec上争几个月也不会有结果。
b*******s
发帖数: 5216
33
comp & swap一样是原子性的非阻塞算法,x86里486时代开始支持的指令
我今天主要是打赵策吧

【在 g*****g 的大作中提到】
: 操,你早干嘛去了。我说用comp&swap, 你跟魏太监可是拼命嘲笑我。现在知道自己傻
: 逼了?半瓶醋下回别跟我现了。

S*A
发帖数: 7142
34
这个似乎不解决两个路段的问题。

【在 b*******s 的大作中提到】
: 不用原子加和减就用comp & swap咯,也是原子性的
: 非0就是被占了,直接失败
: 伪代码如下
: int compare_and_swap (int* reg, int oldval, int newval)
: {
: ATOMIC();
: int old_reg_val = *reg;
: if (old_reg_val == oldval)
: *reg = newval;
: END_ATOMIC();

n*****t
发帖数: 22014
35
这公平性本来就是风车,你还能拿着网吧的收据找车站说这张票是俺的?

【在 a***n 的大作中提到】
: 这个可以自动重试吧,只要加个随机的延时就可以。这样的conflict本来就是时差是小
: 于1ms了,随机一下也谈不上损害公平性的问题吧。

g*****g
发帖数: 34805
36
正确性不是用概率保证的,谁也不保证后面还有单子,你的重刷同样有可能因为同样的
原因废掉。DB transaction能保证正确性,这个不行,还要争什么。

【在 a***n 的大作中提到】
: 这个可以自动重试吧,只要加个随机的延时就可以。这样的conflict本来就是时差是小
: 于1ms了,随机一下也谈不上损害公平性的问题吧。

b*******s
发帖数: 5216
37
这个我在另一帖里说过,联票这种事务性的在前面或中间做
一站失败就回滚,复杂度也是很低的

【在 S*A 的大作中提到】
: 这个似乎不解决两个路段的问题。
g*****g
发帖数: 34805
38
我早说必须用comp&swap, 魏太监可是拼命嘲笑我。现在该还回去了,他这辈子只能永
远做太监了。comp&swap的性能跟decrement不能比也不用我指出吧。

【在 b*******s 的大作中提到】
: comp & swap一样是原子性的非阻塞算法,x86里486时代开始支持的指令
: 我今天主要是打赵策吧

a****i
发帖数: 1182
39
这个,如果两边都是同肯发请求,只要b->c的没刷到,a->b的就一直卖不出去
说“早晚”这个没法满足需求
你设成abc也要分段锁的吧,虚拟了abc,那a->b是有票还是没票?

【在 n*****t 的大作中提到】
: 第一,我不 care 这种情况,买不到的人会不断刷屏,早晚卖出去
: 第二,如果一定要处理,我把 abc 设为一个虚拟车次

S*A
发帖数: 7142
40
我上面給出了一个Wei 的改进算法可以解决这个问题,
帮忙看看有什么漏洞?

【在 b*******s 的大作中提到】
: 这个我在另一帖里说过,联票这种事务性的在前面或中间做
: 一站失败就回滚,复杂度也是很低的

相关主题
真让老魏讨论需求时候,老魏就开始打滚了zz 12306是怎样做成的
做presentation要简单明了阿从12306来看,国内IT水平不高
哥决定常驻这个版了扯两句魏老师vs好虫
进入Programming版参与讨论
t****t
发帖数: 6806
41
compare and swap和xadd一类的没什么区别, 我觉得你想错了.

【在 b*******s 的大作中提到】
: 这个我在另一帖里说过,联票这种事务性的在前面或中间做
: 一站失败就回滚,复杂度也是很低的

n*****t
发帖数: 22014
42
一堆人对着 http 500 狂按 F5,你那玩意再正确有屁用啊

【在 g*****g 的大作中提到】
: 正确性不是用概率保证的,谁也不保证后面还有单子,你的重刷同样有可能因为同样的
: 原因废掉。DB transaction能保证正确性,这个不行,还要争什么。

z****g
发帖数: 75
43
你是给脸不要脸,不说话不大有人知道你这么矬

【在 g*****g 的大作中提到】
: 我早说必须用comp&swap, 魏太监可是拼命嘲笑我。现在该还回去了,他这辈子只能永
: 远做太监了。comp&swap的性能跟decrement不能比也不用我指出吧。

b*******s
发帖数: 5216
44
他那个也可以的呀,比如16个核上16个线程抢,只要保证有效数大于16不就行了?
错误率不会很高的

【在 g*****g 的大作中提到】
: 我早说必须用comp&swap, 魏太监可是拼命嘲笑我。现在该还回去了,他这辈子只能永
: 远做太监了。comp&swap的性能跟decrement不能比也不用我指出吧。

b*******s
发帖数: 5216
45
哦,我再想想

【在 t****t 的大作中提到】
: compare and swap和xadd一类的没什么区别, 我觉得你想错了.
S*A
发帖数: 7142
46
我觉得也是。
这个问题关键是分两段,我 27 楼有个解法等拍砖。

【在 t****t 的大作中提到】
: compare and swap和xadd一类的没什么区别, 我觉得你想错了.
n*****t
发帖数: 22014
47
如果这俩人一直同时按 F5 那就是捣乱,我随便挑一个扔出去宰了算

【在 a****i 的大作中提到】
: 这个,如果两边都是同肯发请求,只要b->c的没刷到,a->b的就一直卖不出去
: 说“早晚”这个没法满足需求
: 你设成abc也要分段锁的吧,虚拟了abc,那a->b是有票还是没票?

g*****g
发帖数: 34805
48
你这傻逼,刚刚得瑟,力吗就被打脸。就你丫也配跟我装。

【在 z****g 的大作中提到】
: 你是给脸不要脸,不说话不大有人知道你这么矬
T********i
发帖数: 2416
49
别无耻了,compexch也有一样的问题。你分明是当时没搞懂。
你说,comp3xch怎么解决有票不能出的问题了?

【在 g*****g 的大作中提到】
: 我早说必须用comp&swap, 魏太监可是拼命嘲笑我。现在该还回去了,他这辈子只能永
: 远做太监了。comp&swap的性能跟decrement不能比也不用我指出吧。

a****i
发帖数: 1182
50
只许一个人抢?另一个没抢到就不许抢了?

【在 n*****t 的大作中提到】
: 如果这俩人一直同时按 F5 那就是捣乱,我随便挑一个扔出去宰了算
相关主题
潜水员上来评价一下这几天的混战,乔峰大战鸠摩智搞技术的,要有起码的是非观念 by 老魏
没干过大数据云计算的不用琢磨12306了其实就是两党党争
qxc,我接招了,你给的要求太弱的,给你加强了赌约在此
进入Programming版参与讨论
g*****g
发帖数: 34805
51
正确性不是个概率问题。有错就不行。你们QA测试拿个边际,难道你说出错概率不大就
不管了?

【在 b*******s 的大作中提到】
: 他那个也可以的呀,比如16个核上16个线程抢,只要保证有效数大于16不就行了?
: 错误率不会很高的

n*****t
发帖数: 22014
52
我意思这种情况狠少发生,不信你琢磨琢磨,哪有那么巧每次都撞上啊

【在 a****i 的大作中提到】
: 只许一个人抢?另一个没抢到就不许抢了?
g*****g
发帖数: 34805
53
反正你的decrement可耻的失败了,现在你也承认你做一辈子太监了。别的我有必要跟
你解释吗?

【在 T********i 的大作中提到】
: 别无耻了,compexch也有一样的问题。你分明是当时没搞懂。
: 你说,comp3xch怎么解决有票不能出的问题了?

S*A
发帖数: 7142
54
靠,我再 27 楼有个改进版的没有这个要用户从新试的问题。
等砖头。
z****e
发帖数: 54598
55
两个车次怎么在同一批DECRE的?

【在 n*****t 的大作中提到】
: 古德八是 abc vs ab,ab 和 bc 是 2 个车次
z****g
发帖数: 75
56
话说你这样的这辈子没戏了,你这脑子就这样了,保佑下辈子投胎聪明点吧

【在 g*****g 的大作中提到】
: 你这傻逼,刚刚得瑟,力吗就被打脸。就你丫也配跟我装。
g*****g
发帖数: 34805
57
你别整了,稍微复杂一点,他的性能就要挂了。

【在 S*A 的大作中提到】
: 靠,我再 27 楼有个改进版的没有这个要用户从新试的问题。
: 等砖头。

S*A
发帖数: 7142
58
这个我觉得应该改好了啊,就是多一个 atomic dec。
CPU 性能应该没有多大影响。
当然网络性能另说。

【在 g*****g 的大作中提到】
: 你别整了,稍微复杂一点,他的性能就要挂了。
T********i
发帖数: 2416
59
这人给他一根杆子就能顺着爬上去。
xadd和compexch到现在还搞不懂。
极品呀。

【在 z****g 的大作中提到】
: 话说你这样的这辈子没戏了,你这脑子就这样了,保佑下辈子投胎聪明点吧
n*****t
发帖数: 22014
60
一个车次没问题了吧?
那你把 2 个高频转车的设想成新的虚拟车次就行了,就好比某次车延线了

【在 z****e 的大作中提到】
: 两个车次怎么在同一批DECRE的?
相关主题
简单介绍一下老魏的结构这么多讨论的,你们用过12306吗?
静态计数器和订票系统的区别操!本版连interlocked指令都没有懂的?
请老魏给出一个简单的文字解释goodbug又丢人了
进入Programming版参与讨论
z****e
发帖数: 54598
61
老魏,我说的是一种极端糟糕的情况,也就是理论上
当你dec前面的时候,达到最后了,因为量太大,最后怎么都是负数
所以无法出票的情况,这种可能性比较小,但是当N->无穷,这种情况是必然出现的
天朝人又多,我比较倾向于这种情况会出现
你可以用现实不可能存在来反驳
顺便说一下,1989那个排队的解法我不反对

【在 T********i 的大作中提到】
: 没啥了不起的。相当于某人reserve一张票,2us以后退掉了。
: 谁让你的线程比人家慢几纳秒呢?运气不好你悲愤啥?
: 18倍的人抢票,1趟车放票可以在毫秒级抢完。剩下几张,而且不会超过10张,因为只
: 有10个线程。有几毫秒震荡,问题大么?
: 几毫秒抢完,和几秒抢完,用户体验有区别么?
: 这么多人抢票,几秒内出结果,没有挤压踩踏,人身伤亡,已经是和谐社会了?
: 你要分析处理器电路量子效应寻求绝对公平么?

b*******s
发帖数: 5216
62
你这个限制就是参与抢票的不能多过票数是吧

【在 S*A 的大作中提到】
: 这个问题我有一个不是很严格的解法,大家看看可不可以行得通。
: 之所以出现这种情况,是因为抢票得计数器不是严格递减的。
: 这样可以再引入另外一组计数器 B,在 commit 出票以后 atomic dec。
: 原来可递减可增加的叫计数器 A。
: 1: 然后抢票的时候,先看递减计数器 B,如果 《 0, 推出不用抢了。
: 2: 如果 》=0, 抢票,用A数组抢票。
: 3: 如果每个票段 抢票结果 A 》 0, 出票, B --
: 4: 如果《0, A++;到1:处循环。
: 这样似乎可以避免有票出不了的情况。
: 大家请拍砖头。

g*****g
发帖数: 34805
63
你这么整,车次就要指数级上升,卖票出去之后,需要更新的计数器也指数级上升。

【在 n*****t 的大作中提到】
: 一个车次没问题了吧?
: 那你把 2 个高频转车的设想成新的虚拟车次就行了,就好比某次车延线了

n*****t
发帖数: 22014
64
负数就洗洗睡了啊,前面正数的拿票走人,买不到联程的相当于退票

【在 z****e 的大作中提到】
: 老魏,我说的是一种极端糟糕的情况,也就是理论上
: 当你dec前面的时候,达到最后了,因为量太大,最后怎么都是负数
: 所以无法出票的情况,这种可能性比较小,但是当N->无穷,这种情况是必然出现的
: 天朝人又多,我比较倾向于这种情况会出现
: 你可以用现实不可能存在来反驳
: 顺便说一下,1989那个排队的解法我不反对

b*******s
发帖数: 5216
65
嗯,在魏老师方案里是一样的

【在 b*******s 的大作中提到】
: 哦,我再想想
S*A
发帖数: 7142
66
可以啊,就是出现票被抢了,但是又没有出的情况
要多循环一两次。用户不需要知道。

【在 b*******s 的大作中提到】
: 你这个限制就是参与抢票的不能多过票数是吧
z****e
发帖数: 54598
67
哈?那就会出现开一半,然后下车,等明天再上车的情况
农民工会起义的

【在 n*****t 的大作中提到】
: 负数就洗洗睡了啊,前面正数的拿票走人,买不到联程的相当于退票
n*****t
发帖数: 22014
68
不可能指数,本来转车就没几个,广大群众的基本策略是买到一张再说

【在 g*****g 的大作中提到】
: 你这么整,车次就要指数级上升,卖票出去之后,需要更新的计数器也指数级上升。
z****e
发帖数: 54598
69
黄牛党会用挖比特币的机器跟你抢的
起一堆肉鸡,然后一声令下

【在 n*****t 的大作中提到】
: 如果这俩人一直同时按 F5 那就是捣乱,我随便挑一个扔出去宰了算
S*A
发帖数: 7142
70
好吧,我宣布 27 楼的解法可以解决好虫提出来的问题。
不需要用户从新订票,多个循环就可以了。
相关主题
goodbug又丢人了做presentation要简单明了阿
我来写个老魏的详细实现方案。(更新了缺点)哥决定常驻这个版了
真让老魏讨论需求时候,老魏就开始打滚了zz 12306是怎样做成的
进入Programming版参与讨论
b*******s
发帖数: 5216
71
我又跟我自己设计的那个内存数据结构搞了,我那个里面不统计票数,而是按位置锁的

【在 b*******s 的大作中提到】
: 嗯,在魏老师方案里是一样的
n*****t
发帖数: 22014
72
啥情况啊,你整明白 interlock 原理没啊?100 张票, 1000 个人抢,100 个返回正
数、出票,跟后面 900 个卢瑟毛关系没有

【在 z****e 的大作中提到】
: 哈?那就会出现开一半,然后下车,等明天再上车的情况
: 农民工会起义的

b*******s
发帖数: 5216
73
循环几次?

【在 S*A 的大作中提到】
: 好吧,我宣布 27 楼的解法可以解决好虫提出来的问题。
: 不需要用户从新订票,多个循环就可以了。

g*****g
发帖数: 34805
74
http://www.mitbbs.com/article_t/Java/31112931.html
顺带看看这个帖子就知道我懂不懂atomic了,发帖时间4年前,远早于这次吵架。太监
拿出个AtomicInteger还以为我没见过,真是太丢人。
z****e
发帖数: 54598
75
老魏不会是看上次我说了这个类,今天拿出来说的吧?
我当时说了三个int, Integer & AutomicInteger的例子
第一和第三不会有问题,第二就不能保证了

【在 g*****g 的大作中提到】
: http://www.mitbbs.com/article_t/Java/31112931.html
: 顺带看看这个帖子就知道我懂不懂atomic了,发帖时间4年前,远早于这次吵架。太监
: 拿出个AtomicInteger还以为我没见过,真是太丢人。

S*A
发帖数: 7142
76
要看冲突情况了。这个问题就跟 spinlock 要循环几次
是一样的啊。但肯定不会死锁。

【在 b*******s 的大作中提到】
: 循环几次?
n*****t
发帖数: 22014
77
你也得刚好在我的线程池里撞上,刚好 abc 先锁

【在 z****e 的大作中提到】
: 黄牛党会用挖比特币的机器跟你抢的
: 起一堆肉鸡,然后一声令下

z****e
发帖数: 54598
78
问题是后面900个不能保证时间上人家就在后面阿

【在 n*****t 的大作中提到】
: 啥情况啊,你整明白 interlock 原理没啊?100 张票, 1000 个人抢,100 个返回正
: 数、出票,跟后面 900 个卢瑟毛关系没有

z****e
发帖数: 54598
79
我的意思是这个数量可能远不是18倍,而是18000倍

【在 n*****t 的大作中提到】
: 你也得刚好在我的线程池里撞上,刚好 abc 先锁
g*****g
发帖数: 34805
80
你代表广大民工了?本来北京还能睡井底,到上海过年睡大街?

【在 n*****t 的大作中提到】
: 不可能指数,本来转车就没几个,广大群众的基本策略是买到一张再说
相关主题
从12306来看,国内IT水平不高没干过大数据云计算的不用琢磨12306了
扯两句魏老师vs好虫qxc,我接招了,你给的要求太弱的,给你加强了
潜水员上来评价一下这几天的混战,乔峰大战鸠摩智搞技术的,要有起码的是非观念 by 老魏
进入Programming版参与讨论
n*****t
发帖数: 22014
81
你也没法拿 timestamp 找我打官司不是?对铁老大来说,卖完了就拉倒,对卢瑟来说
活该倒霉,本来就有可能网络卡一下

【在 z****e 的大作中提到】
: 问题是后面900个不能保证时间上人家就在后面阿
g*****g
发帖数: 34805
82
你就简单来个sync block, 性能恐怕比你这个try and error还好。至少完成时间有保
障。

【在 S*A 的大作中提到】
: 要看冲突情况了。这个问题就跟 spinlock 要循环几次
: 是一样的啊。但肯定不会死锁。

z****g
发帖数: 75
83
不用汇总排列。根据车次决定去哪个NIC->Thread就行了

【在 z****e 的大作中提到】
: 也就是在前端做一个汇总,然后排列,然后再依次送到它那台机器上去了?
: 我这么理解没错吧?
: 那这个理论上有异步的嫌疑,我更喜欢1989那个孩子说的方案
: 也就无法实现REALTIME了
:
: thread

n*****t
发帖数: 22014
84
上海大街比北京暖和,睡完大街你还能转中巴,再说了,转车的 pattern 有历史出票
记录,整几个虚拟车就是了

【在 g*****g 的大作中提到】
: 你代表广大民工了?本来北京还能睡井底,到上海过年睡大街?
T********i
发帖数: 2416
85
你的问题在于不知道atomicint操作后还有返回值,以及返回值怎么用。
从你纠缠compexch来看,你根本就是迄今都不懂。
这个懂行的看得很清楚。眼里揉不得沙子的。

【在 g*****g 的大作中提到】
: http://www.mitbbs.com/article_t/Java/31112931.html
: 顺带看看这个帖子就知道我懂不懂atomic了,发帖时间4年前,远早于这次吵架。太监
: 拿出个AtomicInteger还以为我没见过,真是太丢人。

a***n
发帖数: 538
86
optimistic locking失败以后当然要rollback的。
i*****o
发帖数: 1714
87
不同车次的呢?

★ 发自iPhone App: ChineseWeb 8.6

【在 z****g 的大作中提到】
: 不用汇总排列。根据车次决定去哪个NIC->Thread就行了
b*******s
发帖数: 5216
88
抢票机没有用,我们解释过了,只有在余票不多时才会出现古德霸的那个用例
S*A
发帖数: 7142
89
sync block 是要锁全部线程,每个时刻只有一个线程能有进展吗?
那个性能肯定不如这个。
当然网络 IO 的问题还是有待验证。

【在 g*****g 的大作中提到】
: 你就简单来个sync block, 性能恐怕比你这个try and error还好。至少完成时间有保
: 障。

a***n
发帖数: 538
90
其实单线程也可以吧,都不需要用原子操作,票少的时候可能还快一点。
相关主题
其实就是两党党争静态计数器和订票系统的区别
赌约在此请老魏给出一个简单的文字解释
简单介绍一下老魏的结构这么多讨论的,你们用过12306吗?
进入Programming版参与讨论
z****e
发帖数: 54598
91
对,那就是1989那个人作的东西

【在 a***n 的大作中提到】
: 其实单线程也可以吧,都不需要用原子操作,票少的时候可能还快一点。
n*****t
发帖数: 22014
92
单线程算力可能不够

【在 a***n 的大作中提到】
: 其实单线程也可以吧,都不需要用原子操作,票少的时候可能还快一点。
q*c
发帖数: 9453
93
是这样,我想叉了。
不过如果 bc 没了, 刷 abc 的就能把 ab 的全堵住,对吧?
这种异步交易问题多多。

【在 b*******s 的大作中提到】
: 抢票机没有用,我们解释过了,只有在余票不多时才会出现古德霸的那个用例
g*****g
发帖数: 34805
94
一个北京-上海-兰州的票贩子,不停大量的发订单,占了所有订单的99%,另外1%是
广大人民的北京-上海单子。
偏偏上海-兰州已经卖完了。很有可能的结果就是北京-上海的票,一张都卖不出去。
大量无效订单不停进来,保证了北京-上海上不了0.
还什么10张,纯粹做了太监往回找脸。
i*****o
发帖数: 1714
95
前面有人说了,抢同一个车次的放到一个线程。

★ 发自iPhone App: ChineseWeb 8.6

【在 a***n 的大作中提到】
: 其实单线程也可以吧,都不需要用原子操作,票少的时候可能还快一点。
b*******s
发帖数: 5216
96
在余票多的时候,不可能出现这个情况
只有剩余很少的票才会

【在 g*****g 的大作中提到】
: 一个北京-上海-兰州的票贩子,不停大量的发订单,占了所有订单的99%,另外1%是
: 广大人民的北京-上海单子。
: 偏偏上海-兰州已经卖完了。很有可能的结果就是北京-上海的票,一张都卖不出去。
: 大量无效订单不停进来,保证了北京-上海上不了0.
: 还什么10张,纯粹做了太监往回找脸。

z****e
发帖数: 54598
97
做好分库就快了

【在 n*****t 的大作中提到】
: 单线程算力可能不够
z****e
发帖数: 54598
98
我们抽象一下
把thread变成一个具体的process
在不同的instance上
差距很大么?
反正都慢下来了

【在 z****g 的大作中提到】
: 不用汇总排列。根据车次决定去哪个NIC->Thread就行了
g*****g
发帖数: 34805
99
谁知道呢,比如还有北京-上海还有1000张票,上海-兰州没有了。票贩子先发了1000
个北京-上海-兰州的单子进来,群众才开始。票贩子不停补充消耗,你北京-上海就
永远上不了0.
1000张很少吗?

【在 b*******s 的大作中提到】
: 在余票多的时候,不可能出现这个情况
: 只有剩余很少的票才会

z****e
发帖数: 54598
100
这个时间一旦大到人能感觉出来
比如我今天上午9点一直刷,都没刷到
下午2点刷的都刷到了
那农民工就有砸了售票处的习惯
不患寡患不均哦

【在 n*****t 的大作中提到】
: 你也没法拿 timestamp 找我打官司不是?对铁老大来说,卖完了就拉倒,对卢瑟来说
: 活该倒霉,本来就有可能网络卡一下

相关主题
操!本版连interlocked指令都没有懂的?真让老魏讨论需求时候,老魏就开始打滚了
goodbug又丢人了做presentation要简单明了阿
我来写个老魏的详细实现方案。(更新了缺点)哥决定常驻这个版了
进入Programming版参与讨论
b*******s
发帖数: 5216
101
你看看我的解释,比如16个核绑了16个线程,实际上n也就是16,而不是1000
同一时刻不会变大

1000

【在 g*****g 的大作中提到】
: 谁知道呢,比如还有北京-上海还有1000张票,上海-兰州没有了。票贩子先发了1000
: 个北京-上海-兰州的单子进来,群众才开始。票贩子不停补充消耗,你北京-上海就
: 永远上不了0.
: 1000张很少吗?

q*c
发帖数: 9453
102
怎么会?人比票多10倍,从一开始票就很少。
刷 abc 的就是可以把 ab 的全堵住。bc 没了, 100万人狂刷 abc, 上 比特机, ab
虽然疯狂 rollback, 但就是一直是负数。
虽然 ab 一张票也没卖。
大家等退票,就能刷一天。

【在 b*******s 的大作中提到】
: 在余票多的时候,不可能出现这个情况
: 只有剩余很少的票才会

b*******s
发帖数: 5216
103
呵呵,我已经解释了两次了,你翻翻我的帖子吧

【在 q*c 的大作中提到】
: 怎么会?人比票多10倍,从一开始票就很少。
: 刷 abc 的就是可以把 ab 的全堵住。bc 没了, 100万人狂刷 abc, 上 比特机, ab
: 虽然疯狂 rollback, 但就是一直是负数。
: 虽然 ab 一张票也没卖。
: 大家等退票,就能刷一天。

z****g
发帖数: 75
104
abc先看一眼不就得了

【在 q*c 的大作中提到】
: 怎么会?人比票多10倍,从一开始票就很少。
: 刷 abc 的就是可以把 ab 的全堵住。bc 没了, 100万人狂刷 abc, 上 比特机, ab
: 虽然疯狂 rollback, 但就是一直是负数。
: 虽然 ab 一张票也没卖。
: 大家等退票,就能刷一天。

T********i
发帖数: 2416
105
上500万DOS attack,谁都别买了。
什么指标能对抗DOS?

【在 q*c 的大作中提到】
: 怎么会?人比票多10倍,从一开始票就很少。
: 刷 abc 的就是可以把 ab 的全堵住。bc 没了, 100万人狂刷 abc, 上 比特机, ab
: 虽然疯狂 rollback, 但就是一直是负数。
: 虽然 ab 一张票也没卖。
: 大家等退票,就能刷一天。

n*****t
发帖数: 22014
106
abc 的无法保证每次都抢在 ab 前面,所以每次都有漏网的,要不了几秒就彻底卖完了

【在 q*c 的大作中提到】
: 怎么会?人比票多10倍,从一开始票就很少。
: 刷 abc 的就是可以把 ab 的全堵住。bc 没了, 100万人狂刷 abc, 上 比特机, ab
: 虽然疯狂 rollback, 但就是一直是负数。
: 虽然 ab 一张票也没卖。
: 大家等退票,就能刷一天。

q*c
发帖数: 9453
107
怎么先看?难道前面说的逐段 lockdecrement 不就是看吗?
你有别的两段式交易,就有别的死法。

【在 z****g 的大作中提到】
: abc先看一眼不就得了
b*******s
发帖数: 5216
108
这样线程间负载不均衡

【在 i*****o 的大作中提到】
: 前面有人说了,抢同一个车次的放到一个线程。
:
: ★ 发自iPhone App: ChineseWeb 8.6

z****g
发帖数: 75
109
DDoS另外话题,我有方案搞定

【在 T********i 的大作中提到】
: 上500万DOS attack,谁都别买了。
: 什么指标能对抗DOS?

q*c
发帖数: 9453
110
那不一定,只要 abc 人够多就能一直保证负数,你前面还没 rllback 后面的
decrement 就来了。

【在 n*****t 的大作中提到】
: abc 的无法保证每次都抢在 ab 前面,所以每次都有漏网的,要不了几秒就彻底卖完了
相关主题
哥决定常驻这个版了扯两句魏老师vs好虫
zz 12306是怎样做成的潜水员上来评价一下这几天的混战,乔峰大战鸠摩智
从12306来看,国内IT水平不高没干过大数据云计算的不用琢磨12306了
进入Programming版参与讨论
g*****g
发帖数: 34805
111
就算你这16核的做法真有效,一个车段丢16张票,一天1000车次各20段,3种票,理论
上一天可能有最多
96万的票明明有却卖不出去。近百万的票子没卖掉,上亿得损失,你负担得起这个政治
责任吗?

【在 b*******s 的大作中提到】
: 呵呵,我已经解释了两次了,你翻翻我的帖子吧
L***n
发帖数: 6727
112
同一时间抢票的只能是线程数那么多个人,并不是成千上万的人,所以余票
够多就没问题,老魏是这个意思吧

【在 q*c 的大作中提到】
: 怎么会?人比票多10倍,从一开始票就很少。
: 刷 abc 的就是可以把 ab 的全堵住。bc 没了, 100万人狂刷 abc, 上 比特机, ab
: 虽然疯狂 rollback, 但就是一直是负数。
: 虽然 ab 一张票也没卖。
: 大家等退票,就能刷一天。

z****g
发帖数: 75
113
是有这个问题,但是这个不均衡情况是可以态调整的

【在 b*******s 的大作中提到】
: 这样线程间负载不均衡
b*******s
发帖数: 5216
114
有人已经给了解决了,也是很体面的解决

【在 g*****g 的大作中提到】
: 就算你这16核的做法真有效,一个车段丢16张票,一天1000车次各20段,3种票,理论
: 上一天可能有最多
: 96万的票明明有却卖不出去。近百万的票子没卖掉,上亿得损失,你负担得起这个政治
: 责任吗?

z****e
发帖数: 54598
115
就是分层,爆WEB SERVER
所以古德霸说过要上cloud阿

【在 z****g 的大作中提到】
: 是有这个问题,但是这个不均衡情况是可以态调整的
b*******s
发帖数: 5216
116
比按请求数进行负载分配复杂,不提倡

【在 z****g 的大作中提到】
: 是有这个问题,但是这个不均衡情况是可以态调整的
n*****t
发帖数: 22014
117
10 个靠,假设还剩一张,最多也就把计数器减到 -9 了,人再多也得乖乖的排队等前
面 +1 才能进来捣乱

【在 L***n 的大作中提到】
: 同一时间抢票的只能是线程数那么多个人,并不是成千上万的人,所以余票
: 够多就没问题,老魏是这个意思吧

b*******s
发帖数: 5216
118
ssa提供了一个解决,只要在票数小于线程数时用就行
也就是一个原子操作的负担,一下子就没有了

【在 g*****g 的大作中提到】
: 就算你这16核的做法真有效,一个车段丢16张票,一天1000车次各20段,3种票,理论
: 上一天可能有最多
: 96万的票明明有却卖不出去。近百万的票子没卖掉,上亿得损失,你负担得起这个政治
: 责任吗?

g*****g
发帖数: 34805
119
啥,现在要上什么负载分配啦?太监得单机刷decrement都冗余不多,你这不是要它得
命吗?

【在 b*******s 的大作中提到】
: 比按请求数进行负载分配复杂,不提倡
T********i
发帖数: 2416
120
你又蠢了是不是,任何时候最多10张,也不是丢。

【在 g*****g 的大作中提到】
: 就算你这16核的做法真有效,一个车段丢16张票,一天1000车次各20段,3种票,理论
: 上一天可能有最多
: 96万的票明明有却卖不出去。近百万的票子没卖掉,上亿得损失,你负担得起这个政治
: 责任吗?

相关主题
qxc,我接招了,你给的要求太弱的,给你加强了赌约在此
搞技术的,要有起码的是非观念 by 老魏简单介绍一下老魏的结构
其实就是两党党争静态计数器和订票系统的区别
进入Programming版参与讨论
b*******s
发帖数: 5216
121
开多线程当然也要均衡一下的咯,保证每个线程的负载差不多

【在 g*****g 的大作中提到】
: 啥,现在要上什么负载分配啦?太监得单机刷decrement都冗余不多,你这不是要它得
: 命吗?

g*****g
发帖数: 34805
122
我老觉得它那机器,已经不行了,serialization/deserialization这么重得操作都还
没谈。

【在 b*******s 的大作中提到】
: 开多线程当然也要均衡一下的咯,保证每个线程的负载差不多
b*******s
发帖数: 5216
123
我觉得没什么问题

【在 g*****g 的大作中提到】
: 我老觉得它那机器,已经不行了,serialization/deserialization这么重得操作都还
: 没谈。

L***n
发帖数: 6727
124
我现在也有点convinced了,按老魏说的那个spec,应该没问题

都还

【在 b*******s 的大作中提到】
: 我觉得没什么问题
b*******s
发帖数: 5216
125
其实讨论的内容就是三四个月前的东西
那时连我在内没几个人看懂了魏老师的方案
背景导致的
魏老师省略了很多背景知识,他觉得都是常识

【在 L***n 的大作中提到】
: 我现在也有点convinced了,按老魏说的那个spec,应该没问题
:
: 都还

a***n
发帖数: 538
126
你这个1,2之间有间隔。

【在 S*A 的大作中提到】
: 这个问题我有一个不是很严格的解法,大家看看可不可以行得通。
: 之所以出现这种情况,是因为抢票得计数器不是严格递减的。
: 这样可以再引入另外一组计数器 B,在 commit 出票以后 atomic dec。
: 原来可递减可增加的叫计数器 A。
: 1: 然后抢票的时候,先看递减计数器 B,如果 《 0, 推出不用抢了。
: 2: 如果 》=0, 抢票,用A数组抢票。
: 3: 如果每个票段 抢票结果 A 》 0, 出票, B --
: 4: 如果《0, A++;到1:处循环。
: 这样似乎可以避免有票出不了的情况。
: 大家请拍砖头。

S*A
发帖数: 7142
127
多谢肯定。我觉一直用好了,不需要分票少的是时候用。
那个就是出票才有 automic dec。和后面的network IO比,
完全可以忽略不记。
这样程序还简单。

【在 b*******s 的大作中提到】
: ssa提供了一个解决,只要在票数小于线程数时用就行
: 也就是一个原子操作的负担,一下子就没有了

b*******s
发帖数: 5216
128
就是在票数上spin lock,没票了就回家,有票大于线程数就go ahead
否则就等着,需要等的也就是抢十几张票的时间,us级别的

【在 a***n 的大作中提到】
: 你这个1,2之间有间隔。
n*****t
发帖数: 22014
129
1 那个地方用锁

【在 a***n 的大作中提到】
: 你这个1,2之间有间隔。
b*******s
发帖数: 5216
130
一直用会带来阻塞

【在 S*A 的大作中提到】
: 多谢肯定。我觉一直用好了,不需要分票少的是时候用。
: 那个就是出票才有 automic dec。和后面的network IO比,
: 完全可以忽略不记。
: 这样程序还简单。

相关主题
请老魏给出一个简单的文字解释goodbug又丢人了
这么多讨论的,你们用过12306吗?我来写个老魏的详细实现方案。(更新了缺点)
操!本版连interlocked指令都没有懂的?真让老魏讨论需求时候,老魏就开始打滚了
进入Programming版参与讨论
g*****g
发帖数: 34805
131
你觉得有用吗?把接口拿出来,我上量一测就知道了。太监就是个光说不练的。

【在 b*******s 的大作中提到】
: 我觉得没什么问题
b*******s
发帖数: 5216
132
回头我再说,现在有点累

【在 n*****t 的大作中提到】
: 1 那个地方用锁
S*A
发帖数: 7142
133
有间隔,但是不影响结果。
因为 B 是严格递减的,可能出现 B 》 0 但是
A 抢不到票的情况,后面进入循环从新试到 B 《 0 就好了。

【在 a***n 的大作中提到】
: 你这个1,2之间有间隔。
t****t
发帖数: 6806
134
他一共就10个core在算票, 你发1000个单子有什么用...

1000

【在 g*****g 的大作中提到】
: 谁知道呢,比如还有北京-上海还有1000张票,上海-兰州没有了。票贩子先发了1000
: 个北京-上海-兰州的单子进来,群众才开始。票贩子不停补充消耗,你北京-上海就
: 永远上不了0.
: 1000张很少吗?

b*******s
发帖数: 5216
135
等老魏吧,我一直不做是因为user level tcp我不怎么懂

【在 g*****g 的大作中提到】
: 你觉得有用吗?把接口拿出来,我上量一测就知道了。太监就是个光说不练的。
g*****g
发帖数: 34805
136
操,1000个车次,20段,3种票,每天最多96万张票卖不出去,上亿的损失。
不是丢,卖不出去,票是会过期的,太监。

【在 T********i 的大作中提到】
: 你又蠢了是不是,任何时候最多10张,也不是丢。
S*A
发帖数: 7142
137
什么情况驻塞?
如果票很多,自然 A 》 0, 本部就不会进入循环。
能进入循环肯定都是潜在可能丢票的情况。
没有多余的循环。

【在 b*******s 的大作中提到】
: 一直用会带来阻塞
g*****g
发帖数: 34805
138
一车次丢10*3*20= 600张已经够多了,还要怎样?

【在 t****t 的大作中提到】
: 他一共就10个core在算票, 你发1000个单子有什么用...
:
: 1000

b*******s
发帖数: 5216
139
不会丢的

【在 g*****g 的大作中提到】
: 一车次丢10*3*20= 600张已经够多了,还要怎样?
a***n
发帖数: 538
140
但是还是可能不停回滚最后一张票的情况。

【在 S*A 的大作中提到】
: 有间隔,但是不影响结果。
: 因为 B 是严格递减的,可能出现 B 》 0 但是
: A 抢不到票的情况,后面进入循环从新试到 B 《 0 就好了。

相关主题
真让老魏讨论需求时候,老魏就开始打滚了zz 12306是怎样做成的
做presentation要简单明了阿从12306来看,国内IT水平不高
哥决定常驻这个版了扯两句魏老师vs好虫
进入Programming版参与讨论
S*A
发帖数: 7142
141
补充一下,你说那个票是不是多于 core 的数目是有 race condition 的。
你先看一下票有多少,票很多就去抢,但是进入抢的时候那个票就可能
是已经从很多变成不多了。这里是个 race。
g*****g
发帖数: 34805
142
票会过期的,车都开了,你说没丢有用吗?票贩子可是可以24小时不间断刷票的。

【在 b*******s 的大作中提到】
: 不会丢的
b*******s
发帖数: 5216
143
就是一瞬间的事情,不会拖延到开车,除非你开车前几个毫秒内去买票

【在 g*****g 的大作中提到】
: 票会过期的,车都开了,你说没丢有用吗?票贩子可是可以24小时不间断刷票的。
S*A
发帖数: 7142
144
你举例说名吧,我不知道你想的情况。
按照时间顺序每个thread 分别发生什么。

【在 a***n 的大作中提到】
: 但是还是可能不停回滚最后一张票的情况。
n*****t
发帖数: 22014
145
你当农民工煞笔啊,没票不会按 F5 啊?

【在 g*****g 的大作中提到】
: 票会过期的,车都开了,你说没丢有用吗?票贩子可是可以24小时不间断刷票的。
L***n
发帖数: 6727
146
也没有在开车前几个毫秒还卖票的

【在 b*******s 的大作中提到】
: 就是一瞬间的事情,不会拖延到开车,除非你开车前几个毫秒内去买票
g*****g
发帖数: 34805
147
刷得过票贩子机器刷?最后几场票要刷到就是个概率问题,票贩子hold的概率高太多了。

【在 n*****t 的大作中提到】
: 你当农民工煞笔啊,没票不会按 F5 啊?
t****t
发帖数: 6806
148
任何时候总共没卖出去的票就是10张.

【在 g*****g 的大作中提到】
: 一车次丢10*3*20= 600张已经够多了,还要怎样?
n*****t
发帖数: 22014
149
切,好像票贩子的问题你能用数据库解决似的

了。

【在 g*****g 的大作中提到】
: 刷得过票贩子机器刷?最后几场票要刷到就是个概率问题,票贩子hold的概率高太多了。
i*****o
发帖数: 1714
150
按老魏的算法应该是三十张。

★ 发自iPhone App: ChineseWeb 8.6

【在 g*****g 的大作中提到】
: 一车次丢10*3*20= 600张已经够多了,还要怎样?
相关主题
潜水员上来评价一下这几天的混战,乔峰大战鸠摩智搞技术的,要有起码的是非观念 by 老魏
没干过大数据云计算的不用琢磨12306了其实就是两党党争
qxc,我接招了,你给的要求太弱的,给你加强了赌约在此
进入Programming版参与讨论
n*****t
发帖数: 22014
151
每抢一轮,总有一个幸运的家伙抱走女神,OOXX 10 下也没多少时间

【在 i*****o 的大作中提到】
: 按老魏的算法应该是三十张。
:
: ★ 发自iPhone App: ChineseWeb 8.6

S*A
发帖数: 7142
152
还在争有票卖不出去的情况,不是都有可以避免这个问题用的方案了吗。
n*****t
发帖数: 22014
153
因为总有人听不明白

【在 S*A 的大作中提到】
: 还在争有票卖不出去的情况,不是都有可以避免这个问题用的方案了吗。
L***n
发帖数: 6727
154
如果余票小于10而且一轮中全是abc的request可能一张票也没出,不过
这些request也都迅速出局了所以民工兄弟等几(毫)秒还是能得到ab的票

【在 n*****t 的大作中提到】
: 每抢一轮,总有一个幸运的家伙抱走女神,OOXX 10 下也没多少时间
g*****g
发帖数: 34805
155
如何30张?一车次20车段,3种票,计数器60个,怎么都不会是30张。

【在 i*****o 的大作中提到】
: 按老魏的算法应该是三十张。
:
: ★ 发自iPhone App: ChineseWeb 8.6

S*A
发帖数: 7142
156
好吧,你们继续聊吧,我撤了。
g*****g
发帖数: 34805
157
为啥不行?票贩子的那些abc都是失败的transaction, 我按照timestamp人民ab的票是
成功的transaction.

【在 n*****t 的大作中提到】
: 切,好像票贩子的问题你能用数据库解决似的
:
: 了。

i*****o
发帖数: 1714
158
如果同一车次在一个core上排队呢?

★ 发自iPhone App: ChineseWeb 8.6

【在 g*****g 的大作中提到】
: 如何30张?一车次20车段,3种票,计数器60个,怎么都不会是30张。
g*****g
发帖数: 34805
159
新的 request还会近来的,民工的request也失败了。死循环。

【在 L***n 的大作中提到】
: 如果余票小于10而且一轮中全是abc的request可能一张票也没出,不过
: 这些request也都迅速出局了所以民工兄弟等几(毫)秒还是能得到ab的票

n*****t
发帖数: 22014
160
你这还是让 abc 先失败,换汤不换药

【在 g*****g 的大作中提到】
: 为啥不行?票贩子的那些abc都是失败的transaction, 我按照timestamp人民ab的票是
: 成功的transaction.

相关主题
简单介绍一下老魏的结构这么多讨论的,你们用过12306吗?
静态计数器和订票系统的区别操!本版连interlocked指令都没有懂的?
请老魏给出一个简单的文字解释goodbug又丢人了
进入Programming版参与讨论
L***n
发帖数: 6727
161
小于10的余票有special的处理啊...

【在 g*****g 的大作中提到】
: 新的 request还会近来的,民工的request也失败了。死循环。
g*****g
发帖数: 34805
162
你又要继续提高复杂度了吗?我提醒你太监已经在走钢丝,随便一个补丁性能就不够了。

【在 i*****o 的大作中提到】
: 如果同一车次在一个core上排队呢?
:
: ★ 发自iPhone App: ChineseWeb 8.6

t****t
发帖数: 6806
163
简单的算术么. 如果有N个线程在工作, 那spurious taken ticket最多就是N. 哪有什
么96万张卖不出去的票.
当然可以说每个真的request进来都正好不巧有10个假的request把它盖掉.

【在 L***n 的大作中提到】
: 如果余票小于10而且一轮中全是abc的request可能一张票也没出,不过
: 这些request也都迅速出局了所以民工兄弟等几(毫)秒还是能得到ab的票

n*****t
发帖数: 22014
164
就凭你说 60 张票,你压根没整明白咋回事。
要不你问问赵策去?

了。

【在 g*****g 的大作中提到】
: 你又要继续提高复杂度了吗?我提醒你太监已经在走钢丝,随便一个补丁性能就不够了。
g*****g
发帖数: 34805
165
你说的没错,因为车次不同。只要是并行的,就有可能永远民工的跟贩子的同时执行,
而且贩子的先执行。
正确性不是赌大运。不能因为概率小就说它不会发生。而且如果票贩子占了99。99%呢
?概率就很大了。
我就不提公平性完全不管了。

【在 t****t 的大作中提到】
: 简单的算术么. 如果有N个线程在工作, 那spurious taken ticket最多就是N. 哪有什
: 么96万张卖不出去的票.
: 当然可以说每个真的request进来都正好不巧有10个假的request把它盖掉.

n*****t
发帖数: 22014
166
你听说过哪个脑残票贩倒腾联程票的?

【在 g*****g 的大作中提到】
: 你说的没错,因为车次不同。只要是并行的,就有可能永远民工的跟贩子的同时执行,
: 而且贩子的先执行。
: 正确性不是赌大运。不能因为概率小就说它不会发生。而且如果票贩子占了99。99%呢
: ?概率就很大了。
: 我就不提公平性完全不管了。

g*****g
发帖数: 34805
167
QA弄个edge case, 你就说不fix吗?正确性还有什么可以争的。
而且需要啥联票,北京到上海的票剩下北京到天津一段,票贩子买北京到上海不行吗?

【在 n*****t 的大作中提到】
: 你听说过哪个脑残票贩倒腾联程票的?
n*****t
发帖数: 22014
168
要买北京到上海的,是从上海开始减的 。。。

【在 g*****g 的大作中提到】
: QA弄个edge case, 你就说不fix吗?正确性还有什么可以争的。
: 而且需要啥联票,北京到上海的票剩下北京到天津一段,票贩子买北京到上海不行吗?

a***n
发帖数: 538
169
嗯,确实不会有不出票的情况。不过所有的票要排序出,否则会有可能两个线程死锁。
而且还是有可能第三个人把票抢走了。

【在 S*A 的大作中提到】
: 你举例说名吧,我不知道你想的情况。
: 按照时间顺序每个thread 分别发生什么。

g*****g
发帖数: 34805
170
擦,就剩一个天津到连云港没卖,票贩子先下了北京到连云港,天津到上海,你再来。

【在 n*****t 的大作中提到】
: 要买北京到上海的,是从上海开始减的 。。。
相关主题
goodbug又丢人了做presentation要简单明了阿
我来写个老魏的详细实现方案。(更新了缺点)哥决定常驻这个版了
真让老魏讨论需求时候,老魏就开始打滚了zz 12306是怎样做成的
进入Programming版参与讨论
g*****g
发帖数: 34805
171
要排序太监的系统又挂了。本来就是走钢丝。

【在 a***n 的大作中提到】
: 嗯,确实不会有不出票的情况。不过所有的票要排序出,否则会有可能两个线程死锁。
: 而且还是有可能第三个人把票抢走了。

n*****t
发帖数: 22014
172
你个票贩子还能保证每次都抢前面不成?就算你行,最后 10 张震荡票,我开始加锁保
护,票贩子滚蛋了,天津到连云港就卖了

【在 g*****g 的大作中提到】
: 擦,就剩一个天津到连云港没卖,票贩子先下了北京到连云港,天津到上海,你再来。
g*****g
发帖数: 34805
173
靠,总算服软加锁保护,早干嘛去了。谁不知道有正确的做法,就是从头到位枷锁保护。
但别忘了,500万/秒的订单过来抢这10张票,绝大部分是abc, 你一加锁那排队处理可
就不是1秒能搞定的了。
大量没处理就timeout了。

【在 n*****t 的大作中提到】
: 你个票贩子还能保证每次都抢前面不成?就算你行,最后 10 张震荡票,我开始加锁保
: 护,票贩子滚蛋了,天津到连云港就卖了

S*A
发帖数: 7142
174
不需要用户排序,抢票的时候按照A数组下标顺序抢就
可以避免获得票的循序问题。
这个改良算法倒是没有问题。
有问题的是我怀疑那个 IO 方面的。
还有掉电这些。

【在 g*****g 的大作中提到】
: 要排序太监的系统又挂了。本来就是走钢丝。
n*****t
发帖数: 22014
175
我一早就说加锁,老魏这个更优化,一开始不用加锁。
另外,你真的以为加锁开销很大?

护。

【在 g*****g 的大作中提到】
: 靠,总算服软加锁保护,早干嘛去了。谁不知道有正确的做法,就是从头到位枷锁保护。
: 但别忘了,500万/秒的订单过来抢这10张票,绝大部分是abc, 你一加锁那排队处理可
: 就不是1秒能搞定的了。
: 大量没处理就timeout了。

z****e
发帖数: 54598
176
这么说太拗口
简单点
计数器能用来替换锁
好了

【在 n*****t 的大作中提到】
: 我一早就说加锁,老魏这个更优化,一开始不用加锁。
: 另外,你真的以为加锁开销很大?
:
: 护。

g*****g
发帖数: 34805
177
他是decrement被打脸了,一堆人帮他打补丁找脸吧,尊重一下事实好不好。
他用decrement恶毒问候我家人,结果backfire了。

【在 n*****t 的大作中提到】
: 我一早就说加锁,老魏这个更优化,一开始不用加锁。
: 另外,你真的以为加锁开销很大?
:
: 护。

n*****t
发帖数: 22014
178
差不多这意思,关键让 DB 随便分别了

【在 z****e 的大作中提到】
: 这么说太拗口
: 简单点
: 计数器能用来替换锁
: 好了

1 (共1页)
进入Programming版参与讨论
相关主题
简单介绍一下老魏的结构做presentation要简单明了阿
静态计数器和订票系统的区别哥决定常驻这个版了
请老魏给出一个简单的文字解释zz 12306是怎样做成的
这么多讨论的,你们用过12306吗?从12306来看,国内IT水平不高
操!本版连interlocked指令都没有懂的?扯两句魏老师vs好虫
goodbug又丢人了潜水员上来评价一下这几天的混战,乔峰大战鸠摩智
我来写个老魏的详细实现方案。(更新了缺点)没干过大数据云计算的不用琢磨12306了
真让老魏讨论需求时候,老魏就开始打滚了qxc,我接招了,你给的要求太弱的,给你加强了
相关话题的讨论汇总
话题: 问题话题: 车次话题: decrement话题: 测试用例话题: 保证