s*****e
发帖数: 16824 | 1 排队非实时系统是没用的，因为内在逻辑其实自相矛盾：这么搞就是为了系统有更多的
时间优化出票，但是排队非实时本身其实就放弃任何优化的可能。排队非实时系统为了
保证公平，必须做到严格按照时间戳来售票，先来后到。如果你搞优化，把后面的优化
到前面去了，就没有公信力了，尤其是万一就剩最后一张票，前面的人被后面的优化掉
，你看会是什么结果？绝对比现在骂得惨得多。
再一个就是排队系统对黄牛太有利了，黄牛可以大量的抢位置，具体可以参见倒卖ipad
，iphone的黄牛。而且你的排队系统公不公开？不公开，没有公信力，公开的话，黄牛
可以根据自己占到的位置自由倒票，可以等到自己占的那位置排到首位以后退票再买回
，比现在这种秒杀制把握还要大得多。 |
g*****g
发帖数: 34805 | 2 排队没有公信力，就现在这么随机扔订单，撞大运有公信力？时间戳精确到毫秒，处理
又不需要精确到毫秒级的先后，并行的处理，基本上保证前一分钟到的先处理后一分钟
后处理就行了。
这么说吧，现在这系统一高峰基本死去活来，一堆结点崩了重启，重启完了你刚好拍马
赶到，你就定上了。纯粹撞大运。
如果黄牛能雇几千民工，不同ip，不同身份证抢票，谁也没办法。就跟雇几千民工果子
店前排队，没啥好说的。
ipad
【在 s*****e 的大作中提到】
: 排队非实时系统是没用的，因为内在逻辑其实自相矛盾：这么搞就是为了系统有更多的
: 时间优化出票，但是排队非实时本身其实就放弃任何优化的可能。排队非实时系统为了
: 保证公平，必须做到严格按照时间戳来售票，先来后到。如果你搞优化，把后面的优化
: 到前面去了，就没有公信力了，尤其是万一就剩最后一张票，前面的人被后面的优化掉
: ，你看会是什么结果？绝对比现在骂得惨得多。
: 再一个就是排队系统对黄牛太有利了，黄牛可以大量的抢位置，具体可以参见倒卖ipad
: ，iphone的黄牛。而且你的排队系统公不公开？不公开，没有公信力，公开的话，黄牛
: 可以根据自己占到的位置自由倒票，可以等到自己占的那位置排到首位以后退票再买回
: ，比现在这种秒杀制把握还要大得多。
|
s*****e
发帖数: 16824 | 3 秒杀比排队还是有公信力，起码那就是比运气，绝无人工干预的可能，排队一搞十几分
钟几小时后出结果，你要是严格按时间来还就算了，但那其实跟秒杀是一回事，要是不
严格，绝对比秒杀被骂得惨。
而且我说了，秒杀对黄牛不利，比如现在这样，他抢到票以后想倒给另外一个人是有风
险的，他退票以后不一定能抢回来，而且还可以采取一些措施遏制，比如退的票我不马
上放出来，隔几个小时再放出来，黄牛要抢回来难度就更大了。但是排队制的话，他等
到想倒的那个人排到首位了再退就一点风险没有，而且你晚放票也没用，不管拖几个小
时，他排首位你也得给他。
【在 g*****g 的大作中提到】
: 排队没有公信力，就现在这么随机扔订单，撞大运有公信力？时间戳精确到毫秒，处理
: 又不需要精确到毫秒级的先后，并行的处理，基本上保证前一分钟到的先处理后一分钟
: 后处理就行了。
: 这么说吧，现在这系统一高峰基本死去活来，一堆结点崩了重启，重启完了你刚好拍马
: 赶到，你就定上了。纯粹撞大运。
: 如果黄牛能雇几千民工，不同ip，不同身份证抢票，谁也没办法。就跟雇几千民工果子
: 店前排队，没啥好说的。
:
: ipad
|
l**********n
发帖数: 8443 | |
g*****g
发帖数: 34805 | 5 要避免黄牛就得退票要钱。我要是圣诞想回家退票不要钱我可以包个专机，前一天再退
。12306不合理罢了。
【在 s*****e 的大作中提到】
: 秒杀比排队还是有公信力，起码那就是比运气，绝无人工干预的可能，排队一搞十几分
: 钟几小时后出结果，你要是严格按时间来还就算了，但那其实跟秒杀是一回事，要是不
: 严格，绝对比秒杀被骂得惨。
: 而且我说了，秒杀对黄牛不利，比如现在这样，他抢到票以后想倒给另外一个人是有风
: 险的，他退票以后不一定能抢回来，而且还可以采取一些措施遏制，比如退的票我不马
: 上放出来，隔几个小时再放出来，黄牛要抢回来难度就更大了。但是排队制的话，他等
: 到想倒的那个人排到首位了再退就一点风险没有，而且你晚放票也没用，不管拖几个小
: 时，他排首位你也得给他。
|
g*****g
发帖数: 34805 | 6 抢票的另一后果就是冷门线路躺枪了。我就想接人查个时刻表也趟枪了。 |
n*****t
发帖数: 22014 | 7 退票 random 上架其实不错，黄牛刷了半小时不知道是被别人秒掉了还是没上架，哈哈
还有一个就是资格预审，刷票前先存钱，利用网银、支付宝做身份绑定。刷票/退票频
率高的直接扔小黑屋去。
【在 s*****e 的大作中提到】
: 秒杀比排队还是有公信力，起码那就是比运气，绝无人工干预的可能，排队一搞十几分
: 钟几小时后出结果，你要是严格按时间来还就算了，但那其实跟秒杀是一回事，要是不
: 严格，绝对比秒杀被骂得惨。
: 而且我说了，秒杀对黄牛不利，比如现在这样，他抢到票以后想倒给另外一个人是有风
: 险的，他退票以后不一定能抢回来，而且还可以采取一些措施遏制，比如退的票我不马
: 上放出来，隔几个小时再放出来，黄牛要抢回来难度就更大了。但是排队制的话，他等
: 到想倒的那个人排到首位了再退就一点风险没有，而且你晚放票也没用，不管拖几个小
: 时，他排首位你也得给他。
|
l**********n
发帖数: 8443 | |
b*******s
发帖数: 5216 | 9 春运是刚需，退票费是挡不住黄牛加价的
【在 g*****g 的大作中提到】
: 要避免黄牛就得退票要钱。我要是圣诞想回家退票不要钱我可以包个专机，前一天再退
: 。12306不合理罢了。
|
s*****e
发帖数: 16824 | 10 其实也没用，黄牛也有办法的，据说有些黄牛是专门等到开车前2小时退票，这时候你
没办法，一定是马上就把退票放出来了，不然很可能卖不出去，而这个时候还会来买这
趟车的人非常少了，黄牛就有很大的把握把票拿回来。所以random上架也只能遏制，不
可能阻止黄牛的。总之人是吃这碗饭的，研究这个系统的动力比我们要足得多。
【在 n*****t 的大作中提到】
: 退票 random 上架其实不错，黄牛刷了半小时不知道是被别人秒掉了还是没上架，哈哈
: 还有一个就是资格预审，刷票前先存钱，利用网银、支付宝做身份绑定。刷票/退票频
: 率高的直接扔小黑屋去。
|
|
|
g*****g
发帖数: 34805 | 11 有 waiting list, 实名制，转让能行？黄牛能猜到客户姓名？ |
l**********n
发帖数: 8443 | |
s*****e
发帖数: 16824 | 13 先把票买了占着，然后找客户，然后用客户的信息排队，啥时候客户排第一了，啥时候
把票退了，自然转给客户。
【在 g*****g 的大作中提到】
: 有 waiting list, 实名制，转让能行？黄牛能猜到客户姓名？
|
g*****g
发帖数: 34805 | 14 想啥呢，实名制，再规定最后多少天不许退票。比如20天预售，waiting list保留10天
，这期间可以退票。黄牛先拿单子后找人一点戏没有。
【在 s*****e 的大作中提到】
: 先把票买了占着，然后找客户，然后用客户的信息排队，啥时候客户排第一了，啥时候
: 把票退了，自然转给客户。
|
n*****t
发帖数: 22014 | 15 预付款就行了，一个账号最近退票超过 3 次直接没收
【在 s*****e 的大作中提到】
: 先把票买了占着，然后找客户，然后用客户的信息排队，啥时候客户排第一了，啥时候
: 把票退了，自然转给客户。
|
s*****e
发帖数: 16824 | 16 你见过提前10天就不能退票的系统？这个系统你敢搞出来，绝对被人骂成猪头。
【在 g*****g 的大作中提到】
: 想啥呢，实名制，再规定最后多少天不许退票。比如20天预售，waiting list保留10天
: ，这期间可以退票。黄牛先拿单子后找人一点戏没有。
|
s*****e
发帖数: 16824 | 17 黄牛有几百个账户，他小心控制一下不会超过限制的。
【在 n*****t 的大作中提到】
: 预付款就行了，一个账号最近退票超过 3 次直接没收
|
g*****g
发帖数: 34805 | 18 你设计成两天也是一样的，先例很多。
【在 s*****e 的大作中提到】
: 你见过提前10天就不能退票的系统？这个系统你敢搞出来，绝对被人骂成猪头。
|
s*****e
发帖数: 16824 | 19 早说过，靠罚钱没用，你罚一倍黄牛都照样卖得出去，况且你真罚到一倍，真有事要退
票的也得骂你了。
【在 g*****g 的大作中提到】
: 你设计成两天也是一样的，先例很多。
|
g*****g
发帖数: 34805 | 20 有 waiting list, 黄牛一张都卖不出去。只能做代购。
【在 s*****e 的大作中提到】
: 早说过，靠罚钱没用，你罚一倍黄牛都照样卖得出去，况且你真罚到一倍，真有事要退
: 票的也得骂你了。
|
|
|
n*****t
发帖数: 22014 | 21 预付款就要几百个支付宝账号或网银，身份认定比 12306 严格多了，而且费的还是别
人资源。身份证用过 2-3 次就废了，你还会把身份证借给黄牛不？反正我不会。
【在 s*****e 的大作中提到】
: 黄牛有几百个账户，他小心控制一下不会超过限制的。
|
s*****e
发帖数: 16824 | 22 你不会，有的是人会。你看国内炒股的，也是动不动就借几百个的身份证，大部分都是
民工，给点钱很多人愿意。
【在 n*****t 的大作中提到】
: 预付款就要几百个支付宝账号或网银，身份认定比 12306 严格多了，而且费的还是别
: 人资源。身份证用过 2-3 次就废了，你还会把身份证借给黄牛不？反正我不会。
|
n*****t
发帖数: 22014 | 23 民工更不借了，哈哈，人家要回家过年的。我看可以整个火车票票，凭户口本、居委会
大妈盖章、单位介绍信、派出所证明，而且限定路线。
【在 s*****e 的大作中提到】
: 你不会，有的是人会。你看国内炒股的，也是动不动就借几百个的身份证，大部分都是
: 民工，给点钱很多人愿意。
|
s*****e
发帖数: 16824 | 24 又不是所有民工都是离乡背井的，况且还有留守农村的老头老太呢，都可以借的。你说
的这种就是以前大学的学生票，能解决一部分问题，但是大多数民工拿不到什么介绍信
的。
【在 n*****t 的大作中提到】
: 民工更不借了，哈哈，人家要回家过年的。我看可以整个火车票票，凭户口本、居委会
: 大妈盖章、单位介绍信、派出所证明，而且限定路线。
|
l*****9
发帖数: 9501 | 25 杜绝黄牛很简单：
1。先登记身份证和付费方式后订票；
2。订票时加个自动购买的选择，这类订票优先，
3。不即时出排队结果
4。订票不成功的上waiting list
5。票和订票都和身份证挂钩，不能改
6。退票20%手续费
卖票还有其他考虑，全程优先。
假如3000张票，20000个订单，其中10000张黄牛（不自动购买），10000张真实订票（
自动购买）
3000张真实订票购票成功，17000上waiting list
既然有了排号，就不会不断刷票。只要黄牛不敢自动购买，就抢不过真实乘客。根据
waiting list,可以加临客。足够多全程乘客，可以改中间停靠客站。 |
b*******s
发帖数: 5216 | 26 炒房的就是几百个身份证
【在 s*****e 的大作中提到】
: 你不会，有的是人会。你看国内炒股的，也是动不动就借几百个的身份证，大部分都是
: 民工，给点钱很多人愿意。
|
d******e
发帖数: 2265 | 27 你根本不知道你在第几位。在server里面都是黑的。
所以无所谓抢不强。
ipad
【在 s*****e 的大作中提到】
: 排队非实时系统是没用的，因为内在逻辑其实自相矛盾：这么搞就是为了系统有更多的
: 时间优化出票，但是排队非实时本身其实就放弃任何优化的可能。排队非实时系统为了
: 保证公平，必须做到严格按照时间戳来售票，先来后到。如果你搞优化，把后面的优化
: 到前面去了，就没有公信力了，尤其是万一就剩最后一张票，前面的人被后面的优化掉
: ，你看会是什么结果？绝对比现在骂得惨得多。
: 再一个就是排队系统对黄牛太有利了，黄牛可以大量的抢位置，具体可以参见倒卖ipad
: ，iphone的黄牛。而且你的排队系统公不公开？不公开，没有公信力，公开的话，黄牛
: 可以根据自己占到的位置自由倒票，可以等到自己占的那位置排到首位以后退票再买回
: ，比现在这种秒杀制把握还要大得多。
|
b*******s
发帖数: 5216 | 28 民工现在很多都是包大巴回家，多出来几百个身份证很简单
【在 n*****t 的大作中提到】
: 民工更不借了，哈哈，人家要回家过年的。我看可以整个火车票票，凭户口本、居委会
: 大妈盖章、单位介绍信、派出所证明，而且限定路线。
|
b*******s
发帖数: 5216 | 29 说实话，这设计够烂的，前面那么多人指出的缺陷敢情你都没看
【在 l*****9 的大作中提到】
: 杜绝黄牛很简单：
: 1。先登记身份证和付费方式后订票；
: 2。订票时加个自动购买的选择，这类订票优先，
: 3。不即时出排队结果
: 4。订票不成功的上waiting list
: 5。票和订票都和身份证挂钩，不能改
: 6。退票20%手续费
: 卖票还有其他考虑，全程优先。
: 假如3000张票，20000个订单，其中10000张黄牛（不自动购买），10000张真实订票（
: 自动购买）
|
l*****9
发帖数: 9501 | 30 指出具体缺陷，我看不出黄牛怎么赚钱，提前找到真实乘客代购车票算合法生意
【在 b*******s 的大作中提到】
: 说实话，这设计够烂的，前面那么多人指出的缺陷敢情你都没看
|
|
|
l*****9
发帖数: 9501 | 31 你有一千个身份证又怎样？只要你不敢直接购票，你就排在后面。你直接购票，车票上
的身份证不能改，退票罚款，你退了票，被已经在waiting list上的人拿到，你能卖给
谁？
【在 b*******s 的大作中提到】
: 说实话，这设计够烂的，前面那么多人指出的缺陷敢情你都没看
|
q*c
发帖数: 9453 | 32 1。 排队可以控制时间窗口 － 在一窗口内有上百万的交易， 完全可以充分优化。
窗口内不严格按时间。 窗口内全部优先级等价。
2。黄牛更好对付， 先设置 payment 再提交需求， 需求满足立刻买票， 退票 30% 手
续费。
排队空开啥？ 公开你在哪个窗口里。 窗口内部随机没有顺序。
政府连64 那么多人都镇压的下去， 区区黄牛算个毛。 这事情根本是政治问题， 就像
房价一样，是有人不许你解决， 而不是不能解决的技术问题。
ipad
【在 s*****e 的大作中提到】
: 排队非实时系统是没用的，因为内在逻辑其实自相矛盾：这么搞就是为了系统有更多的
: 时间优化出票，但是排队非实时本身其实就放弃任何优化的可能。排队非实时系统为了
: 保证公平，必须做到严格按照时间戳来售票，先来后到。如果你搞优化，把后面的优化
: 到前面去了，就没有公信力了，尤其是万一就剩最后一张票，前面的人被后面的优化掉
: ，你看会是什么结果？绝对比现在骂得惨得多。
: 再一个就是排队系统对黄牛太有利了，黄牛可以大量的抢位置，具体可以参见倒卖ipad
: ，iphone的黄牛。而且你的排队系统公不公开？不公开，没有公信力，公开的话，黄牛
: 可以根据自己占到的位置自由倒票，可以等到自己占的那位置排到首位以后退票再买回
: ，比现在这种秒杀制把握还要大得多。
|
q*c
发帖数: 9453 | 33 用窗口法， 几千民工算啥啊，多少万 多少亿人在抢票， 黄牛能雇佣几个人。
比如每 10 分钟一个窗口， 进行一次批处理。下面 10 分钟系统冷却， 然后出精确剩
余票情况供查询。 查询完了接着 10 分钟窗口接受交易请求。
窗口内全部提交等价， 不进行排序， 进行最大优化。
这样就行了。
【在 g*****g 的大作中提到】
: 排队没有公信力，就现在这么随机扔订单，撞大运有公信力？时间戳精确到毫秒，处理
: 又不需要精确到毫秒级的先后，并行的处理，基本上保证前一分钟到的先处理后一分钟
: 后处理就行了。
: 这么说吧，现在这系统一高峰基本死去活来，一堆结点崩了重启，重启完了你刚好拍马
: 赶到，你就定上了。纯粹撞大运。
: 如果黄牛能雇几千民工，不同ip，不同身份证抢票，谁也没办法。就跟雇几千民工果子
: 店前排队，没啥好说的。
:
: ipad
|
b*******s
发帖数: 5216 | 34 你排队如何scale out？
排队的本质是，后一个人必须等前一个人的订单处理完，否则一直被block
这是你们一直强调的“公平”，也就是不存在插队
不管你有多少台机器，都等待其中一台处理完一个request然后才能继续
排队是把系统变成了一个后台单线程串行化的东西
这个怎么scale out？
请介绍一下？
【在 q*c 的大作中提到】
: 1。 排队可以控制时间窗口 － 在一窗口内有上百万的交易， 完全可以充分优化。
: 窗口内不严格按时间。 窗口内全部优先级等价。
: 2。黄牛更好对付， 先设置 payment 再提交需求， 需求满足立刻买票， 退票 30% 手
: 续费。
: 排队空开啥？ 公开你在哪个窗口里。 窗口内部随机没有顺序。
: 政府连64 那么多人都镇压的下去， 区区黄牛算个毛。 这事情根本是政治问题， 就像
: 房价一样，是有人不许你解决， 而不是不能解决的技术问题。
:
: ipad
|
q*c
发帖数: 9453 | 35 就开交易时间段窗口， 在窗口内没有顺序。 一个active 窗口一个窗口的处理。
又 scale, 又精确（窗口冷却期间只能查询不能买票）， 又能优化, 还能消灭黄牛。
【在 s*****e 的大作中提到】
: 先把票买了占着，然后找客户，然后用客户的信息排队，啥时候客户排第一了，啥时候
: 把票退了，自然转给客户。
|
q*c
发帖数: 9453 | 36 被 两亿 真实用户赞无黄牛欺诈，2000 真有急事退票用户骂， it is OK.
【在 s*****e 的大作中提到】
: 早说过，靠罚钱没用，你罚一倍黄牛都照样卖得出去，况且你真罚到一倍，真有事要退
: 票的也得骂你了。
|
q*c
发帖数: 9453 | 37 那成本就大的太多了。
【在 s*****e 的大作中提到】
: 你不会，有的是人会。你看国内炒股的，也是动不动就借几百个的身份证，大部分都是
: 民工，给点钱很多人愿意。
|
b*******s
发帖数: 5216 | 38 我明白了，你的“排队”是按时间窗口是吧？
比如凌晨1点到2点算一个窗口，在窗口内提交的先处理
在凌晨两点到三点的和未成交的算下一个窗口？
【在 q*c 的大作中提到】
: 就开交易时间段窗口， 在窗口内没有顺序。 一个active 窗口一个窗口的处理。
: 又 scale, 又精确（窗口冷却期间只能查询不能买票）， 又能优化, 还能消灭黄牛。
|
b*******s
发帖数: 5216 | 39 如果真是这样，太恐怖了
【在 b*******s 的大作中提到】
: 我明白了，你的“排队”是按时间窗口是吧？
: 比如凌晨1点到2点算一个窗口，在窗口内提交的先处理
: 在凌晨两点到三点的和未成交的算下一个窗口？
|
q*c
发帖数: 9453 | 40 为什么要排队？ 只有窗口之间有时间优先级， 窗口内根本不排队， 不保证有票， 系
统优化出票。
一旦你有了这个窗口内的全部提交， 窗口关闭， 没有新的交易进来， 所有交易大包
分组去后台处理， 想怎么 scale 就怎么 scale, 办法多的是。 2 分钟全部处理完毕
， 更新系统状态， 更新各级 cache, 开放查询， 等待下一次交易窗口。
本来人多票少， 无论如何根本不能保正出票。
【在 b*******s 的大作中提到】
: 你排队如何scale out？
: 排队的本质是，后一个人必须等前一个人的订单处理完，否则一直被block
: 这是你们一直强调的“公平”，也就是不存在插队
: 不管你有多少台机器，都等待其中一台处理完一个request然后才能继续
: 排队是把系统变成了一个后台单线程串行化的东西
: 这个怎么scale out？
: 请介绍一下？
|
|
|
b*******s
发帖数: 5216 | 41 这个按窗口来的设计说实话，太恐怖了
首先你不能预计窗口内进来多少人，也许几千万人在第一个窗口就进来了
后面的窗口却没有人，这点上我觉得你基本没考虑瞬时高峰这个特点
其次窗口内如果人很多，你顺序处理效率还是有个排队或者竞争的问题
你就考虑这个worst case吧，所有春运需求进了你的第一个窗口
你不觉得你的设计在这个情况下什么问题都没解决吗？
【在 q*c 的大作中提到】
: 为什么要排队？ 只有窗口之间有时间优先级， 窗口内根本不排队， 不保证有票， 系
: 统优化出票。
: 一旦你有了这个窗口内的全部提交， 窗口关闭， 没有新的交易进来， 所有交易大包
: 分组去后台处理， 想怎么 scale 就怎么 scale, 办法多的是。 2 分钟全部处理完毕
: ， 更新系统状态， 更新各级 cache, 开放查询， 等待下一次交易窗口。
: 本来人多票少， 无论如何根本不能保正出票。
|
b*******s
发帖数: 5216 | 42 我给你改一下你的设计，按进来多少个请求来定义窗口，比如每次进来1万个就暂停
不过这设计你觉得好吗？
【在 q*c 的大作中提到】
: 为什么要排队？ 只有窗口之间有时间优先级， 窗口内根本不排队， 不保证有票， 系
: 统优化出票。
: 一旦你有了这个窗口内的全部提交， 窗口关闭， 没有新的交易进来， 所有交易大包
: 分组去后台处理， 想怎么 scale 就怎么 scale, 办法多的是。 2 分钟全部处理完毕
: ， 更新系统状态， 更新各级 cache, 开放查询， 等待下一次交易窗口。
: 本来人多票少， 无论如何根本不能保正出票。
|
b*******s
发帖数: 5216 | 43 说实话，我觉得太丑陋了
【在 b*******s 的大作中提到】
: 我给你改一下你的设计，按进来多少个请求来定义窗口，比如每次进来1万个就暂停
: 不过这设计你觉得好吗？
|
q*c
发帖数: 9453 | 44 对。
这事情就是要避免 实时。 窗口大小根据具体定。
只有窗口之间有时间优先级， 窗口内根本不排队， 不保证有票， 系统优化出票。
其实根本没有两个窗口， 只有一个窗口， 就是当前活跃窗口，这个窗口不处理， 别
的窗口不开。
一旦你有了这个窗口内的全部提交， 窗口关闭， 没有新的交易进来， 所有交易打包
分组去后台处理， 想怎么 scale 就怎么 scale, 办法多的是。 2 分钟全部处理完毕
， 更新系统状态， 更新各级 cache, 开放查询， 等待下一次交易窗口。
本来人多票少， 无论如何根本不能保正出票。
【在 b*******s 的大作中提到】
: 我明白了，你的“排队”是按时间窗口是吧？
: 比如凌晨1点到2点算一个窗口，在窗口内提交的先处理
: 在凌晨两点到三点的和未成交的算下一个窗口？
|
b*******s
发帖数: 5216 | 45 你看看我的回复
【在 q*c 的大作中提到】
: 对。
: 这事情就是要避免 实时。 窗口大小根据具体定。
: 只有窗口之间有时间优先级， 窗口内根本不排队， 不保证有票， 系统优化出票。
: 其实根本没有两个窗口， 只有一个窗口， 就是当前活跃窗口，这个窗口不处理， 别
: 的窗口不开。
: 一旦你有了这个窗口内的全部提交， 窗口关闭， 没有新的交易进来， 所有交易打包
: 分组去后台处理， 想怎么 scale 就怎么 scale, 办法多的是。 2 分钟全部处理完毕
: ， 更新系统状态， 更新各级 cache, 开放查询， 等待下一次交易窗口。
: 本来人多票少， 无论如何根本不能保正出票。
|
q*c
发帖数: 9453 | 46 具体一点， 这比 一边打桌子骂娘， 一面无法打开窗口， 一面不知道缴钱通过没有胡
思乱想可怕恐怖？
你哪个星系过来的？
【在 b*******s 的大作中提到】
: 如果真是这样，太恐怖了
|
b*******s
发帖数: 5216 | 47 我期望的是，有没有，能不能下单，立即知道结果，别浪费时间等了几个小时收到个短
信说没有票
【在 q*c 的大作中提到】
: 具体一点， 这比 一边打桌子骂娘， 一面无法打开窗口， 一面不知道缴钱通过没有胡
: 思乱想可怕恐怖？
: 你哪个星系过来的？
|
q*c
发帖数: 9453 | 48 为什么不能？ 我时间 + 人数 共同控制不行？ 大概到了 100 万就 cut.
你说的情况首先根本不存在， 设想不存在的情况毫无意义， 其次就算出现， 无非是
所有人全部交易一次在场， 没有实时查询需求， 没有各种锁， 前端关闭交易， 后端
自由组合优化， 那好办的狠, 就是上机器就行了。
【在 b*******s 的大作中提到】
: 这个按窗口来的设计说实话，太恐怖了
: 首先你不能预计窗口内进来多少人，也许几千万人在第一个窗口就进来了
: 后面的窗口却没有人，这点上我觉得你基本没考虑瞬时高峰这个特点
: 其次窗口内如果人很多，你顺序处理效率还是有个排队或者竞争的问题
: 你就考虑这个worst case吧，所有春运需求进了你的第一个窗口
: 你不觉得你的设计在这个情况下什么问题都没解决吗？
|
q*c
发帖数: 9453 | 49 很好啊？ 流量低的时候就是连续。 高流量的时候就分段， 有什么问题呢？
你去买票， 窗口还关闭吃饭呢！
【在 b*******s 的大作中提到】
: 我给你改一下你的设计，按进来多少个请求来定义窗口，比如每次进来1万个就暂停
: 不过这设计你觉得好吗？
|
q*c
发帖数: 9453 | 50 嗯。。。还是死机的系统好哇！
【在 b*******s 的大作中提到】
: 说实话，我觉得太丑陋了
|
|
|
b*******s
发帖数: 5216 | 51 时间加人数你还不如直接用人数了，多此一举
你的设计的本质就是到了后台处理能力上限了就停止接受订单
而这个处理能力是和人数正相关的，不是严格，近似
在这个窗口内，你如果不排序，依然要互相竞争抢票，比如100个人一起抢南京到上海
的票，仅仅是客户抢变成了你服务器集群内部抢
如果排序，又变成了依次顺序处理，不能scale out
【在 q*c 的大作中提到】
: 为什么不能？ 我时间 + 人数 共同控制不行？ 大概到了 100 万就 cut.
: 你说的情况首先根本不存在， 设想不存在的情况毫无意义， 其次就算出现， 无非是
: 所有人全部交易一次在场， 没有实时查询需求， 没有各种锁， 前端关闭交易， 后端
: 自由组合优化， 那好办的狠, 就是上机器就行了。
|
q*c
发帖数: 9453 | 52 结果你得到的是， 系统死机 N小时， 你啥也得不到
而且哪里浪费时间几个小时？ 就几分钟的事情。 如果你那个窗口你要的票还有， 那
你怎么也会得到票。 如果你那个窗口票不足， 你也许有也许没有， 但是无论如何，
你不需要反复刷票， 这个窗口票没了， 下一个窗口更加没有（小概率退票事件另外考
虑）
【在 b*******s 的大作中提到】
: 我期望的是，有没有，能不能下单，立即知道结果，别浪费时间等了几个小时收到个短
: 信说没有票
|
q*c
发帖数: 9453 | 53
我的本质就是阻止各种为了实时查询订票需求产生的各种昂贵而无法 scale 的锁。
服务器内枪， 那根本不是问题， 因为那不是抢， 而是根据算法优化出票， 有序的很
, 能任意 scale, 能做的很快。
【在 b*******s 的大作中提到】
: 时间加人数你还不如直接用人数了，多此一举
: 你的设计的本质就是到了后台处理能力上限了就停止接受订单
: 而这个处理能力是和人数正相关的，不是严格，近似
: 在这个窗口内，你如果不排序，依然要互相竞争抢票，比如100个人一起抢南京到上海
: 的票，仅仅是客户抢变成了你服务器集群内部抢
: 如果排序，又变成了依次顺序处理，不能scale out
|
b*******s
发帖数: 5216 | 54 你先别假定会死机，先讨论你的设计
说实话，你的后台你没认真考虑过，实际在你的后台，如果scale out，依然存在复杂
的竞争
，
【在 q*c 的大作中提到】
: 结果你得到的是， 系统死机 N小时， 你啥也得不到
: 而且哪里浪费时间几个小时？ 就几分钟的事情。 如果你那个窗口你要的票还有， 那
: 你怎么也会得到票。 如果你那个窗口票不足， 你也许有也许没有， 但是无论如何，
: 你不需要反复刷票， 这个窗口票没了， 下一个窗口更加没有（小概率退票事件另外考
: 虑）
|
b*******s
发帖数: 5216 | 55 哪来这些复杂的锁哦，后台情况定期同步到cache
而cache server是一个读服务，完全可以scale out
就是暂时和实际出票状况不严格一致罢了
很。
【在 q*c 的大作中提到】
:
: 我的本质就是阻止各种为了实时查询订票需求产生的各种昂贵而无法 scale 的锁。
: 服务器内枪， 那根本不是问题， 因为那不是抢， 而是根据算法优化出票， 有序的很
: , 能任意 scale, 能做的很快。
|
q*c
发帖数: 9453 | 56 那就看你如何定义算法 － 空洞的公平没有意义， 同一个高效的排队优化算法就行了。
【在 b*******s 的大作中提到】
: 你先别假定会死机，先讨论你的设计
: 说实话，你的后台你没认真考虑过，实际在你的后台，如果scale out，依然存在复杂
: 的竞争
:
: ，
|
b*******s
发帖数: 5216 | 57 你做过多线程并发的商业产品吗？
你准备为后台的scale out后的分布在不同服务器上的处理订单的线程做调度？
my god
【在 q*c 的大作中提到】
: 那就看你如何定义算法 － 空洞的公平没有意义， 同一个高效的排队优化算法就行了。
|
q*c
发帖数: 9453 | 58 那你说的订票就有结果就不行， 而且因为有顺序而无法优化。
【在 b*******s 的大作中提到】
: 哪来这些复杂的锁哦，后台情况定期同步到cache
: 而cache server是一个读服务，完全可以scale out
: 就是暂时和实际出票状况不严格一致罢了
:
: 很。
|
b*******s
发帖数: 5216 | 59 又开始排队了？你了解排队意味着什么吗？blocking！
了。
【在 q*c 的大作中提到】
: 那就看你如何定义算法 － 空洞的公平没有意义， 同一个高效的排队优化算法就行了。
|
b*******s
发帖数: 5216 | 60 我说的有顺序？我告诉你，没有
我再费点口水给你解释一下这个cache是怎么工作的
1 cache整个由一个rw－lock保护，只有在后台来更新时才阻塞读，这个更新很短暂，
因为就是个内存裸数组，而大多数时间，读性能很高，没有锁的阻塞，如果你看不懂，
建议去补习rw lock的知识
2 可以根据用户数对cache servers scale out
3 同步是从standby服务器发起的，不影响主服务器效率，standby服务器的数量也是可
以scale out的
【在 q*c 的大作中提到】
: 那你说的订票就有结果就不行， 而且因为有顺序而无法优化。
|
|
|
b*******s
发帖数: 5216 | 61 cache服务器负责查询的服务，而主服务器和standby服务器负责处理锁票的实际操作
在cache服务器上用户查询都是读请求，很高效
【在 b*******s 的大作中提到】
: 我说的有顺序？我告诉你，没有
: 我再费点口水给你解释一下这个cache是怎么工作的
: 1 cache整个由一个rw－lock保护，只有在后台来更新时才阻塞读，这个更新很短暂，
: 因为就是个内存裸数组，而大多数时间，读性能很高，没有锁的阻塞，如果你看不懂，
: 建议去补习rw lock的知识
: 2 可以根据用户数对cache servers scale out
: 3 同步是从standby服务器发起的，不影响主服务器效率，standby服务器的数量也是可
: 以scale out的
|
b*******s
发帖数: 5216 | 62 而且排队对于用户体验是致命的，首先排队就没法scale out，于是用户就只能傻等着
，而不能去订飞机票，船票，汽车票，中途也不能改主意立即撤销，而且等用户排到了
要支付了，也许是已经睡了，或者在不方便支付的环境里，比如在开车，然后错过了，
发现自己在几亿人民后面了，my god，多有趣的设计
了。
【在 q*c 的大作中提到】
: 那就看你如何定义算法 － 空洞的公平没有意义， 同一个高效的排队优化算法就行了。
|
l*****9
发帖数: 9501 | 63 你的艾迪很准确
【在 b*******s 的大作中提到】
: 你排队如何scale out？
: 排队的本质是，后一个人必须等前一个人的订单处理完，否则一直被block
: 这是你们一直强调的“公平”，也就是不存在插队
: 不管你有多少台机器，都等待其中一台处理完一个request然后才能继续
: 排队是把系统变成了一个后台单线程串行化的东西
: 这个怎么scale out？
: 请介绍一下？
|
b*******s
发帖数: 5216 | 64 好吧 给你个例子 假定你的队列里有一百个单子申请同一个座位 你把他们分布到十台
机器了 妳又要保证按时间戳得到结果 你怎么做scale out?
【在 l*****9 的大作中提到】
: 你的艾迪很准确
|
g*****g
发帖数: 34805 | 65 你说的跟我差不多，但也没有必要冷却，想继续交单就让它继续交单好了。10分钟一个
窗口，只保证这个窗口比下个窗口早处理，窗口内不保证顺序。scale很容易的事情。
【在 q*c 的大作中提到】
: 为什么要排队？ 只有窗口之间有时间优先级， 窗口内根本不排队， 不保证有票， 系
: 统优化出票。
: 一旦你有了这个窗口内的全部提交， 窗口关闭， 没有新的交易进来， 所有交易大包
: 分组去后台处理， 想怎么 scale 就怎么 scale, 办法多的是。 2 分钟全部处理完毕
: ， 更新系统状态， 更新各级 cache, 开放查询， 等待下一次交易窗口。
: 本来人多票少， 无论如何根本不能保正出票。
|
g*****g
发帖数: 34805 | 66 无脑的就是不明白，排队只是提交单子而已，实时存到数据库里。后台批处理有的是办
法，
没有啥绝对公平的说法，读一批，发给多个节点处理一批，差不多公平就行了。现在撞
大运叫做公平？
【在 b*******s 的大作中提到】
: 而且排队对于用户体验是致命的，首先排队就没法scale out，于是用户就只能傻等着
: ，而不能去订飞机票，船票，汽车票，中途也不能改主意立即撤销，而且等用户排到了
: 要支付了，也许是已经睡了，或者在不方便支付的环境里，比如在开车，然后错过了，
: 发现自己在几亿人民后面了，my god，多有趣的设计
:
: 了。
|
p*****3
发帖数: 488 | 67
只读cache 需要rw-lock保护吗,不需要strong consistency的说。update的话直接
delete cache不就可以了吗，嫌慢的话甚至可以单开线程load DB更新，然后再atomic
swap
【在 b*******s 的大作中提到】
: 我说的有顺序？我告诉你，没有
: 我再费点口水给你解释一下这个cache是怎么工作的
: 1 cache整个由一个rw－lock保护，只有在后台来更新时才阻塞读，这个更新很短暂，
: 因为就是个内存裸数组，而大多数时间，读性能很高，没有锁的阻塞，如果你看不懂，
: 建议去补习rw lock的知识
: 2 可以根据用户数对cache servers scale out
: 3 同步是从standby服务器发起的，不影响主服务器效率，standby服务器的数量也是可
: 以scale out的
|
b*******s
发帖数: 5216 | 68 你也开始pa咯，这习惯不好
你开始修改你的声明了？开始不强调严格按时间戳处理了？
说实话，不严格按时间戳处理，只要你有多个处理的线程/进程，你依然会面对对同一
个位子的请求的冲突处理，而且这种冲突的频率是不低的，你们只是习惯了依赖数据库
自身的记录的锁来掩盖具体细节，但锁依然是存在的，而且是低效的
我从来没讲过公平，我只讲用户体验，不需要等几个小时告诉你对不起没票了
【在 g*****g 的大作中提到】
: 无脑的就是不明白，排队只是提交单子而已，实时存到数据库里。后台批处理有的是办
: 法，
: 没有啥绝对公平的说法，读一批，发给多个节点处理一批，差不多公平就行了。现在撞
: 大运叫做公平？
|
b*******s
发帖数: 5216 | 69 你的cache是后台要对其进行更新的，可以这么看，后台有一个writer,而前面有无数的
readers
cache的更新也是需要后台协作的，而更新时是block readers的，所以越快越好，
delete后再load一遍不是个好方案，合理的是只load改变了的部分。这个东西不可能保
证strong consistency的
atomic
【在 p*****3 的大作中提到】
:
: 只读cache 需要rw-lock保护吗,不需要strong consistency的说。update的话直接
: delete cache不就可以了吗，嫌慢的话甚至可以单开线程load DB更新，然后再atomic
: swap
|
g*****g
发帖数: 34805 | 70 我从来没说过能严格按照时间戳，我说过能基本按照时间戳，DB transaction是并行的
，不能严格先后。
那天我都估计过了，每天放票10次的话，每次也就120万张票，优化不优话都是几分钟
出完了。超过一个小时，意味着数据库每秒低于300个transaction。你以为pc呀。
啥几个小时才有回应，自己算算吧。
【在 b*******s 的大作中提到】
: 你也开始pa咯，这习惯不好
: 你开始修改你的声明了？开始不强调严格按时间戳处理了？
: 说实话，不严格按时间戳处理，只要你有多个处理的线程/进程，你依然会面对对同一
: 个位子的请求的冲突处理，而且这种冲突的频率是不低的，你们只是习惯了依赖数据库
: 自身的记录的锁来掩盖具体细节，但锁依然是存在的，而且是低效的
: 我从来没讲过公平，我只讲用户体验，不需要等几个小时告诉你对不起没票了
|
|
|
b*******s
发帖数: 5216 | 71 不严格按时间戳处理你要时间戳干嘛？
直接按照订单被处理到的顺序就是了
多此一举
【在 g*****g 的大作中提到】
: 我从来没说过能严格按照时间戳，我说过能基本按照时间戳，DB transaction是并行的
: ，不能严格先后。
: 那天我都估计过了，每天放票10次的话，每次也就120万张票，优化不优话都是几分钟
: 出完了。超过一个小时，意味着数据库每秒低于300个transaction。你以为pc呀。
: 啥几个小时才有回应，自己算算吧。
|
g*****g
发帖数: 34805 | 72 按时间戳排序呀。没时间戳怎么排队？我设计的订单的main key就是 time-based uuid
.
这是分布式数据库，不是单机数据库一次＋1往下写。
【在 b*******s 的大作中提到】
: 不严格按时间戳处理你要时间戳干嘛？
: 直接按照订单被处理到的顺序就是了
: 多此一举
|
b*******s
发帖数: 5216 | 73 你需要排序吗？反正数据库插入也是带锁的，每次都往尾部插就是了
uuid.
【在 g*****g 的大作中提到】
: 按时间戳排序呀。没时间戳怎么排队？我设计的订单的main key就是 time-based uuid
: .
: 这是分布式数据库，不是单机数据库一次＋1往下写。
|
p*****3
发帖数: 488 | 74
我觉得如果处理够快是不是还是可以考虑的，我举个例子
1. 先订票，大并发的时候web service提交大量订票message(请求)存到大量"订票
message queue", 这些都是stateless的，不够可以动态scale。
2. 有一个只读cache的service只提供valid和invalid信息给每个车次，这样更新操作
很少也不需要很强的一致性，这个service用来决策针对用户请求能否定这个车次的位
置，如果可以产生另外一个订票的message到订票的消息队列。这个决策的service也是
stateless, 负责从订票message queue读取用户请求，查询cache, 然后决定选几号列
车。这里所有的也都好scale。
3. 因为前面的service已经知道列车号了，实在不行甚至这一步可以每个列车对应一个
出票message queue, message分到一个列车上面再多又能有多少呢，一台machine
batch获取message, batch处理和更新数据库。应为一张火车票也就是对应一个列车，
就是更新一组[timespan, train_id, seat_id]的信息，一个列车的出票message queue
由一台机器bath处理，这个列车的座位信息放在一个数据库里(当然可以有standby做备
份啥的)也不需要跨多个机器锁来锁去的。
第三步也就是出票失败了re-drive message, time out为3次(或其他策略)，也不是绝
对公平的说，不过差不多了。
感觉这三层可以水平扩展，没准p90就几分钟。
【在 b*******s 的大作中提到】
: 而且排队对于用户体验是致命的，首先排队就没法scale out，于是用户就只能傻等着
: ，而不能去订飞机票，船票，汽车票，中途也不能改主意立即撤销，而且等用户排到了
: 要支付了，也许是已经睡了，或者在不方便支付的环境里，比如在开车，然后错过了，
: 发现自己在几亿人民后面了，my god，多有趣的设计
:
: 了。
|
g*****g
发帖数: 34805 | 75 你又不懂了吧，没有关系数据库能撑住100万／秒的transation。至少x86的没戏。所以
要分布式数据库收订单。
【在 b*******s 的大作中提到】
: 你需要排序吗？反正数据库插入也是带锁的，每次都往尾部插就是了
:
: uuid.
|
p*****3
发帖数: 488 | 76
没有说需要strong consistent的，也有说不直接delete, 是先load然后atomic swap,
所有内存数据结构都是immutable的一整块，没有必要partial update吧。
【在 b*******s 的大作中提到】
: 你的cache是后台要对其进行更新的，可以这么看，后台有一个writer,而前面有无数的
: readers
: cache的更新也是需要后台协作的，而更新时是block readers的，所以越快越好，
: delete后再load一遍不是个好方案，合理的是只load改变了的部分。这个东西不可能保
: 证strong consistency的
:
: atomic
|
b*******s
发帖数: 5216 | 77 按照好虫的设计，存在多种组合，很可能是跨车次的，所以你不能按车次简单来分msg
queue,至少要有个“事务”来同时询问多个车次，都拿到了才算成功。在这种情况下会
有很多复杂的场景，比如两个“事务”分别都请求票A,B，第一个拿住了A，第二个拿住
了B，结果两个都失败了，然后一直没人拿A,B，结果两个事务下单的人就抓狂了，明明
有票，就是拿不到
【在 p*****3 的大作中提到】
:
: 没有说需要strong consistent的，也有说不直接delete, 是先load然后atomic swap,
: 所有内存数据结构都是immutable的一整块，没有必要partial update吧。
|
g*****g
发帖数: 34805 | 78 这种死锁关系数据库已经解决了几十年了，根本不用你操心。简单的实现就是排序的表
，顺序锁，哪会有死锁出现。
对应用是透明的。
msg
【在 b*******s 的大作中提到】
: 按照好虫的设计，存在多种组合，很可能是跨车次的，所以你不能按车次简单来分msg
: queue,至少要有个“事务”来同时询问多个车次，都拿到了才算成功。在这种情况下会
: 有很多复杂的场景，比如两个“事务”分别都请求票A,B，第一个拿住了A，第二个拿住
: 了B，结果两个都失败了，然后一直没人拿A,B，结果两个事务下单的人就抓狂了，明明
: 有票，就是拿不到
|
b*******s
发帖数: 5216 | 79 你都不严格按照顺序了，分布式向多个库写队列很难？你搞个时间戳来做全局排序才叫
不必要吧
【在 g*****g 的大作中提到】
: 你又不懂了吧，没有关系数据库能撑住100万／秒的transation。至少x86的没戏。所以
: 要分布式数据库收订单。
|
b*******s
发帖数: 5216 | 80 你知道什么叫死锁？
【在 g*****g 的大作中提到】
: 这种死锁关系数据库已经解决了几十年了，根本不用你操心。简单的实现就是排序的表
: ，顺序锁，哪会有死锁出现。
: 对应用是透明的。
:
: msg
|
|
|
p*****3
发帖数: 488 | 81
msg
哎~~ 大部分人都是做一个车子嘛~~ 我这辈子还没转过车呢，问题都是先从简单，常见
的情况下手的撒，特殊情况再调整，想那么多很累滴~~
【在 b*******s 的大作中提到】
: 按照好虫的设计，存在多种组合，很可能是跨车次的，所以你不能按车次简单来分msg
: queue,至少要有个“事务”来同时询问多个车次，都拿到了才算成功。在这种情况下会
: 有很多复杂的场景，比如两个“事务”分别都请求票A,B，第一个拿住了A，第二个拿住
: 了B，结果两个都失败了，然后一直没人拿A,B，结果两个事务下单的人就抓狂了，明明
: 有票，就是拿不到
|
g*****g
发帖数: 34805 | 82 你写多个库也不是不行，没有我用cassandra简单，全局排序加上多DC failover。
我用cassandra，流量大了起个节点就完了。你那要改一堆配置，老费劲了。
【在 b*******s 的大作中提到】
: 你都不严格按照顺序了，分布式向多个库写队列很难？你搞个时间戳来做全局排序才叫
: 不必要吧
|
b*******s
发帖数: 5216 | 83 ping-pong buffers？
明白你的意思了，但是这段时间的不一致程度取决于你load的时间的长短，如果是
partial update，不一致性会好一点，具体怎么样看实际数据，也许你的设计更好
,
【在 p*****3 的大作中提到】
:
: msg
: 哎~~ 大部分人都是做一个车子嘛~~ 我这辈子还没转过车呢，问题都是先从简单，常见
: 的情况下手的撒，特殊情况再调整，想那么多很累滴~~
|
b*******s
发帖数: 5216 | 84 哈哈，可以的
【在 g*****g 的大作中提到】
: 你写多个库也不是不行，没有我用cassandra简单，全局排序加上多DC failover。
: 我用cassandra，流量大了起个节点就完了。你那要改一堆配置，老费劲了。
|
g*****g
发帖数: 34805 | 85 你比我老懂？我老上一份工作，就是专门给人优化应用，解决死锁问题。有的死锁两周
才出一次，以你水平根本就不知道怎么解决。
【在 b*******s 的大作中提到】
: 你知道什么叫死锁？
|
b*******s
发帖数: 5216 | 86 嗯，死锁起码有个锁住，不改变条件解不开吧。我说的是两个事务都失败返回了，这叫
死锁？又长知识了
【在 g*****g 的大作中提到】
: 你比我老懂？我老上一份工作，就是专门给人优化应用，解决死锁问题。有的死锁两周
: 才出一次，以你水平根本就不知道怎么解决。
|
b*******s
发帖数: 5216 | 87 又来你老了，你多老了？顺序拿锁这是最基本的知识，就像没有干预就无法破坏锁定才
叫死锁一样，都是最最基本的东西
【在 g*****g 的大作中提到】
: 你比我老懂？我老上一份工作，就是专门给人优化应用，解决死锁问题。有的死锁两周
: 才出一次，以你水平根本就不知道怎么解决。
|
g*****g
发帖数: 34805 | 88 如果你设timeout, 是不会出现你说的这种情况的。你说的这种情况发生就是死锁了。
一直呀，不是一次。
而且不管你失败不失败，顺序锁，就可以保证你说的情况不发生。
“然后一直没人拿A,B，结果两个事务下单的人就抓狂了，明明
有票，就是拿不到”
【在 b*******s 的大作中提到】
: 嗯，死锁起码有个锁住，不改变条件解不开吧。我说的是两个事务都失败返回了，这叫
: 死锁？又长知识了
|
g*****g
发帖数: 34805 | 89 的确太基本了，所以你还拿出来质疑，是体现没有常识吗？
【在 b*******s 的大作中提到】
: 又来你老了，你多老了？顺序拿锁这是最基本的知识，就像没有干预就无法破坏锁定才
: 叫死锁一样，都是最最基本的东西
|
b*******s
发帖数: 5216 | 90 你看东西真的太轻率了，我小再给你老解释下为什么这不是死锁
死锁四条件就不重复了，你自己对比下有没有不满足的。这个场景里，事务的占票需要
先锁定，读是不是还空，空的话写入占住，不空就返回失败。哪有阻塞导致不能返回。
问题是，两个事务都返回了失败，两个单子都又到waiting list里面去了，但是A,B明
明都是还有票的呀
【在 g*****g 的大作中提到】
: 如果你设timeout, 是不会出现你说的这种情况的。你说的这种情况发生就是死锁了。
: 一直呀，不是一次。
: 而且不管你失败不失败，顺序锁，就可以保证你说的情况不发生。
: “然后一直没人拿A,B，结果两个事务下单的人就抓狂了，明明
: 有票，就是拿不到”
|
|
|
b*******s
发帖数: 5216 | 91 你起码要用对术语吧，你指着冰淇淋说蛋糕，这叫什么？
【在 g*****g 的大作中提到】
: 的确太基本了，所以你还拿出来质疑，是体现没有常识吗？
|
b*******s
发帖数: 5216 | 92 而且和timeout有毛关系？
【在 g*****g 的大作中提到】
: 如果你设timeout, 是不会出现你说的这种情况的。你说的这种情况发生就是死锁了。
: 一直呀，不是一次。
: 而且不管你失败不失败，顺序锁，就可以保证你说的情况不发生。
: “然后一直没人拿A,B，结果两个事务下单的人就抓狂了，明明
: 有票，就是拿不到”
|
g*****g
发帖数: 34805 | 93 如果有timeout, 就不会出现死锁，timeout就是干预的一种，这也是常识。
你既然强调了一直拿不到，那就是死锁。
总之这都是基础知识，明明在没问题的地方出来质疑的是你不是我。
【在 b*******s 的大作中提到】
: 而且和timeout有毛关系？
|
b*******s
发帖数: 5216 | 94 我倒是挺怀疑你的常识，对一个live lock说dead lock，还讲timeout和顺序锁，有意思
【在 g*****g 的大作中提到】
: 如果你设timeout, 是不会出现你说的这种情况的。你说的这种情况发生就是死锁了。
: 一直呀，不是一次。
: 而且不管你失败不失败，顺序锁，就可以保证你说的情况不发生。
: “然后一直没人拿A,B，结果两个事务下单的人就抓狂了，明明
: 有票，就是拿不到”
|
b*******s
发帖数: 5216 | 95 这根本不是dead lock，而是live lock，听说过live lock吗？解决方法和顺序锁一点
关系没有，完全是南辕北辙
【在 g*****g 的大作中提到】
: 如果有timeout, 就不会出现死锁，timeout就是干预的一种，这也是常识。
: 你既然强调了一直拿不到，那就是死锁。
: 总之这都是基础知识，明明在没问题的地方出来质疑的是你不是我。
|
g*****g
发帖数: 34805 | 96 对live lock没有说一直的。有timeout就没有一直一说。
没问题的地方跟我长篇大论，还好意思谈常识。
意思
【在 b*******s 的大作中提到】
: 我倒是挺怀疑你的常识，对一个live lock说dead lock，还讲timeout和顺序锁，有意思
|
b*******s
发帖数: 5216 | 97 live lock和timeout没关系，明白不？这么基础的问题，赶紧google学习
【在 g*****g 的大作中提到】
: 对live lock没有说一直的。有timeout就没有一直一说。
: 没问题的地方跟我长篇大论，还好意思谈常识。
:
: 意思
|
g*****g
发帖数: 34805 | 98 一个拿到A，一个拿到B，都不放手，叫live lock? 你丫不要被打脸了就乱找个名词来
应付好不好？
而且live lock为啥不能有timeout, 任何基于db或者queue的操作都可以有 timeout.
【在 b*******s 的大作中提到】
: live lock和timeout没关系，明白不？这么基础的问题，赶紧google学习
|
z****e
发帖数: 54598 | 99 你们在说什么？
但是timeout是最常见的干预
不用加之一，这个古德霸肯定是对的
我随随便便可以给你举出十多种用timeout的机制
最常见的就是session
【在 b*******s 的大作中提到】
: live lock和timeout没关系，明白不？这么基础的问题，赶紧google学习
|
b*******s
发帖数: 5216 | 100 你继续吧，看，你的小伙伴也来了
【在 g*****g 的大作中提到】
: 一个拿到A，一个拿到B，都不放手，叫live lock? 你丫不要被打脸了就乱找个名词来
: 应付好不好？
: 而且live lock为啥不能有timeout, 任何基于db或者queue的操作都可以有 timeout.
|
|
|
e**o
发帖数: 5509 | 101 规定春运期间必须提前12个小时退票。或者提前24，48小时退票。
这样黄牛的把握就小不少。
【在 s*****e 的大作中提到】
: 其实也没用，黄牛也有办法的，据说有些黄牛是专门等到开车前2小时退票，这时候你
: 没办法，一定是马上就把退票放出来了，不然很可能卖不出去，而这个时候还会来买这
: 趟车的人非常少了，黄牛就有很大的把握把票拿回来。所以random上架也只能遏制，不
: 可能阻止黄牛的。总之人是吃这碗饭的，研究这个系统的动力比我们要足得多。
|
l*****9
发帖数: 9501 | 102 规定必须提前24退票,黄牛一退票，waiting list上的人就拿到票了
只要有waiting list，黄牛就滚蛋了
【在 e**o 的大作中提到】
: 规定春运期间必须提前12个小时退票。或者提前24，48小时退票。
: 这样黄牛的把握就小不少。
|
b*******8
发帖数: 37364 | |
