L*****e
发帖数: 8347 | 1 刚才有人说了，老魏的方案是保证不重票，不保证有票不出。。。有票不出就反复刷。
。。
你们俩真是各说各的。。。
★ 发自iPhone App: ChineseWeb 8.2.2 |
|
n*****t
发帖数: 22014 | 2 没那么严重，前面大部分人都能拿到票，临界的会争夺。而且这个 N 没么大，一个车
次一个等级的才冲突 |
|
z****g
发帖数: 75 | 3 还有一种办法就是前端routing的时候，sharding就好了
这货忙了半天就找出个这问题
这个细节问题，我以为这货能自己知道可以解决 |
|
z****e
发帖数: 54598 | 4 当N+1个人同时争抢时候就临界了
这个N当然会很大，别忘了，天朝是运力不足哦 |
|
x****u
发帖数: 44466 | 5 这还没谈到很多更实际的问题呢。
比方说领导可能需要随时调整售票策略。就算需求量再大，也不可能把所有京沪高铁车
票都卖给南京到徐州。但是如果两地间临时有重要事情发生，也许就会在特定日期内允
许此操作。 |
|
n*****t
发帖数: 22014 | 6 其实就算真没票了，热情网友还得不停刷，早卖晚卖对铁老大意义不大，还怕你跑了不
成？ |
|
z****e
发帖数: 54598 | 7 让ROUTING去做这种逻辑貌似就有问题
你给ZKSS
既然你喜欢探究细节的人，那我就问问你这个怎么做的
好吧，我没有PA过你，这个你可以放心说 |
|
z****e
发帖数: 54598 | 8 给你一个数据
天朝春运，铁路总共就是3亿人次不到
而总共出行人次达到36亿
所以这是18倍以上的差距
那么一种极端假设
当座位数是N的时候
18N个人同时抢，会不会出现我说的问题？
很有可能 |
|
n*****t
发帖数: 22014 | 9 大哥，大部分旅客是不转车的，真转车的也是先整到一张再说，还非得靠窗对面是美女
才下单啊？ |
|
|
n*****t
发帖数: 22014 | 11 你非得这么干我也没辙，那就 share code，把常见转车路线做成虚拟车，这个有大量
出票记录可以 build |
|
|
z****e
发帖数: 54598 | 13 行了，理论上致命的缺陷
当然zhuang说可以routing，sharding
那这个我不知道到底怎么回事
让zhuang来说 |
|
z****e
发帖数: 54598 | 14 我说的就是楼主说的问题啊
根转车有什么关系啊？
你说是北京-济南，济南-上海么？ |
|
z****g
发帖数: 75 | 15 总有前端web 服务器吧，在这里把这种请求送到同个NIC，然后这个NIC上就一个thread
，然后就序列化了
当然，我认为实际实现是不必这么做的，重新刷以下就好了 |
|
n*****t
发帖数: 22014 | 16 你说的跟古德八是两个问题 。。。。你俩先掐一掐 |
|
z****e
发帖数: 54598 | 17 也就是在前端做一个汇总，然后排列，然后再依次送到它那台机器上去了？
我这么理解没错吧？
那这个理论上有异步的嫌疑，我更喜欢1989那个孩子说的方案
也就无法实现REALTIME了
thread |
|
b*******s
发帖数: 5216 | 18 不用原子加和减就用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;
} |
|
z****e
发帖数: 54598 | 19 没有啊，我跟你讨论的就是古德霸说的
济南那个是左眼说的 |
|
S*A
发帖数: 7142 | 20 这个问题我有一个不是很严格的解法，大家看看可不可以行得通。
之所以出现这种情况，是因为抢票得计数器不是严格递减的。
这样可以再引入另外一组计数器 B，在 commit 出票以后 atomic dec。
原来可递减可增加的叫计数器 A。
1： 然后抢票的时候，先看递减计数器 B，如果 《 0， 推出不用抢了。
2: 如果 》＝0， 抢票，用A数组抢票。
3: 如果每个票段 抢票结果 A 》 0， 出票， B －－
4: 如果《0， A++；到1:处循环。
这样似乎可以避免有票出不了的情况。
大家请拍砖头。 |
|
g*****g
发帖数: 34805 | 21 操，你早干嘛去了。我说用comp&swap, 你跟魏太监可是拼命嘲笑我。现在知道自己傻
逼了？半瓶醋下回别跟我现了。 |
|
n*****t
发帖数: 22014 | 22 古德八是 abc vs ab，ab 和 bc 是 2 个车次 |
|
T********i
发帖数: 2416 | 23 没啥了不起的。相当于某人reserve一张票，2us以后退掉了。
谁让你的线程比人家慢几纳秒呢？运气不好你悲愤啥？
18倍的人抢票，1趟车放票可以在毫秒级抢完。剩下几张，而且不会超过10张，因为只
有10个线程。有几毫秒震荡，问题大么？
几毫秒抢完，和几秒抢完，用户体验有区别么？
这么多人抢票，几秒内出结果，没有挤压踩踏，人身伤亡，已经是和谐社会了？
你要分析处理器电路量子效应寻求绝对公平么？ |
|
a***n
发帖数: 538 | 24 这个可以自动重试吧，只要加个随机的延时就可以。这样的conflict本来就是时差是小
于1ms了，随机一下也谈不上损害公平性的问题吧。 |
|
d***a
发帖数: 13752 | 25 还在争啊...
其实两人说的spec不一样。第一个不同，应该是系统还是用户决定联票。第二个不同，
能不能有一定的概率在可出票的情况下不出票。spec上争几个月也不会有结果。 |
|
b*******s
发帖数: 5216 | 26 comp & swap一样是原子性的非阻塞算法，x86里486时代开始支持的指令
我今天主要是打赵策吧 |
|
|
n*****t
发帖数: 22014 | 28 这公平性本来就是风车，你还能拿着网吧的收据找车站说这张票是俺的？ |
|
g*****g
发帖数: 34805 | 29 正确性不是用概率保证的，谁也不保证后面还有单子，你的重刷同样有可能因为同样的
原因废掉。DB transaction能保证正确性，这个不行，还要争什么。 |
|
b*******s
发帖数: 5216 | 30 这个我在另一帖里说过，联票这种事务性的在前面或中间做
一站失败就回滚，复杂度也是很低的 |
|
g*****g
发帖数: 34805 | 31 我早说必须用comp&swap, 魏太监可是拼命嘲笑我。现在该还回去了，他这辈子只能永
远做太监了。comp&swap的性能跟decrement不能比也不用我指出吧。 |
|
a****i
发帖数: 1182 | 32 这个，如果两边都是同肯发请求，只要b->c的没刷到，a->b的就一直卖不出去
说“早晚”这个没法满足需求
你设成abc也要分段锁的吧，虚拟了abc，那a->b是有票还是没票？ |
|
S*A
发帖数: 7142 | 33 我上面給出了一个Wei 的改进算法可以解决这个问题，
帮忙看看有什么漏洞？ |
|
t****t
发帖数: 6806 | 34 compare and swap和xadd一类的没什么区别, 我觉得你想错了. |
|
n*****t
发帖数: 22014 | 35 一堆人对着 http 500 狂按 F5，你那玩意再正确有屁用啊 |
|
|
b*******s
发帖数: 5216 | 37 他那个也可以的呀，比如16个核上16个线程抢，只要保证有效数大于16不就行了？
错误率不会很高的 |
|
|
S*A
发帖数: 7142 | 39 我觉得也是。
这个问题关键是分两段，我 27 楼有个解法等拍砖。 |
|
n*****t
发帖数: 22014 | 40 如果这俩人一直同时按 F5 那就是捣乱，我随便挑一个扔出去宰了算 |
|
g*****g
发帖数: 34805 | 41 你这傻逼，刚刚得瑟，力吗就被打脸。就你丫也配跟我装。 |
|
T********i
发帖数: 2416 | 42 别无耻了，compexch也有一样的问题。你分明是当时没搞懂。
你说，comp3xch怎么解决有票不能出的问题了？ |
|
|
n*****t
发帖数: 22014 | 44 我意思这种情况狠少发生，不信你琢磨琢磨，哪有那么巧每次都撞上啊 |
|
g*****g
发帖数: 34805 | 45 反正你的decrement可耻的失败了，现在你也承认你做一辈子太监了。别的我有必要跟
你解释吗？ |
|
S*A
发帖数: 7142 | 46 靠，我再 27 楼有个改进版的没有这个要用户从新试的问题。
等砖头。 |
|
|
z****g
发帖数: 75 | 48 话说你这样的这辈子没戏了，你这脑子就这样了，保佑下辈子投胎聪明点吧 |
|
|
S*A
发帖数: 7142 | 50 这个我觉得应该改好了啊，就是多一个 atomic dec。
CPU 性能应该没有多大影响。
当然网络性能另说。 |
|
