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 设为一个虚拟车次
|
|
|
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
|
|
|
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 的大作中提到】
: 我没有说转车，就一条线的情况就行
|
|
|
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 的大作中提到】
: 这个我在另一帖里说过，联票这种事务性的在前面或中间做
: 一站失败就回滚，复杂度也是很低的
|
|
|
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 那就是捣乱，我随便挑一个扔出去宰了算
|
|
|
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的？
|
|
|
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 楼的解法可以解决好虫提出来的问题。
不需要用户从新订票，多个循环就可以了。 |
|
|
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 的大作中提到】
: 不可能指数，本来转车就没几个，广大群众的基本策略是买到一张再说
|
|
|
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 其实单线程也可以吧，都不需要用原子操作，票少的时候可能还快一点。 |
|
|
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 找我打官司不是？对铁老大来说，卖完了就拉倒，对卢瑟来说
: 活该倒霉，本来就有可能网络卡一下
|
|
|
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 前面，所以每次都有漏网的，要不了几秒就彻底卖完了
|
|
|
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万的票明明有却卖不出去。近百万的票子没卖掉，上亿得损失，你负担得起这个政治
: 责任吗？
|
|
|
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比，
: 完全可以忽略不记。
: 这样程序还简单。
|
|
|
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 就好了。
|
|
|
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张已经够多了，还要怎样？
|
|
|
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 | |
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.
|
|
|
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 的大作中提到】
: 要买北京到上海的，是从上海开始减的 。。。
|
|
|
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 的大作中提到】
: 这么说太拗口
: 简单点
: 计数器能用来替换锁
: 好了
|
