n*****t
发帖数: 22014 | 1 寄信人: TeacherWei (TW)
标 题: 搞技术的，要有起码的是非观念
发信站: 未名空间 (Sun Feb 9 13:47:45 2014)
来 源: 68.
搞技术的，要有起码的是非观念
计算机技术大多数时候是一个binary world，没有较真的精神，也就无乐趣而言。老外
喜欢说 My Pleasure Is My Business。
goodbug那个所谓的分布式分票算法，迄今为止似乎大多数网友都没看出其中的问题。
我被封发贴与此有关，当然我自省其中有我不冷静因素，但是我还要不吐不快。
goodbug定义它的系统是延迟分票系统，不是彩票系统对吧？
延迟分票，只不过是收集用户请求，然后集中分票，然后确认。
彩票系统是，收集用户请求，对于符合条件的用户，如果人多票少。则随机分配。
其中的差别，主要是分票规则，如果人多票少，分给谁？延迟分票，要有先来后到，彩
票系统则不尊重次序。
Cassandra，读写都可以并行，不过有一个条件，就是读写的时候没有数据依赖性。
时间依赖性也是依赖。
问题是，只要goodbug尊重时间，则他那个分布式分票机不论用多少台机器，不可能持
续处理100K/s的请求。为什么？因为处理请求要按照次序，即使这些请求都在内存里面
准备好了，挨着个的看一眼，都不见得100K/s能够看完，更何况处理呢？
除非goodbug不尊重时间优先，也就是有可能同样的条件前一个人刚刚被拒绝，后一个
人票却拿到了。如此一来，goodbug又为什么嘲笑我的计数器震荡问题呢？更何况我的
计数器震荡问题在数分钟内就已经找到了解决办法。
现在回到Cassandra做message queue的问题。还是一样的问题，message queue是否需
要发送和接受要保持顺序？如果需要保持顺序，则整个系统，不论用多少台机器，很难
突破100K/s。如果不需要保持顺序，则无所谓，但是这种情况下再用time based UUID
做key就毫无道理，仍然不及格。
goodbug坚持用time based UUID做key/index，就是要保持次序。
这么简单的东西，有什么好争的呢？
Peking2, wwzz等人，你们明白了么？ |
L*****e
发帖数: 8347 | 2 哦，你已经转了，那我把我转的可以删了。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 n*****t 的大作中提到】
: 寄信人: TeacherWei (TW)
: 标 题: 搞技术的，要有起码的是非观念
: 发信站: 未名空间 (Sun Feb 9 13:47:45 2014)
: 来 源: 68.
: 搞技术的，要有起码的是非观念
: 计算机技术大多数时候是一个binary world，没有较真的精神，也就无乐趣而言。老外
: 喜欢说 My Pleasure Is My Business。
: goodbug那个所谓的分布式分票算法，迄今为止似乎大多数网友都没看出其中的问题。
: 我被封发贴与此有关，当然我自省其中有我不冷静因素，但是我还要不吐不快。
: goodbug定义它的系统是延迟分票系统，不是彩票系统对吧？
|
L*****e
发帖数: 8347 | 3 老魏别的都还不错，就是这个帖子里点名叫板的习惯可以稍微改改。从人情世故来讲，
不应伤及无辜，从斗争策略来讲，不要战线太宽最后疲于应付。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 n*****t 的大作中提到】
: 寄信人: TeacherWei (TW)
: 标 题: 搞技术的，要有起码的是非观念
: 发信站: 未名空间 (Sun Feb 9 13:47:45 2014)
: 来 源: 68.
: 搞技术的，要有起码的是非观念
: 计算机技术大多数时候是一个binary world，没有较真的精神，也就无乐趣而言。老外
: 喜欢说 My Pleasure Is My Business。
: goodbug那个所谓的分布式分票算法，迄今为止似乎大多数网友都没看出其中的问题。
: 我被封发贴与此有关，当然我自省其中有我不冷静因素，但是我还要不吐不快。
: goodbug定义它的系统是延迟分票系统，不是彩票系统对吧？
|
l**********n
发帖数: 8443 | |
L*****e
发帖数: 8347 | 5 这强耦合数据和并行分布处理就是死敌啊。。。
★ 发自iPhone App: ChineseWeb 8.2.2
★ 发自iPhone App: ChineseWeb 8.2.2
【在 n*****t 的大作中提到】
: 寄信人: TeacherWei (TW)
: 标 题: 搞技术的，要有起码的是非观念
: 发信站: 未名空间 (Sun Feb 9 13:47:45 2014)
: 来 源: 68.
: 搞技术的，要有起码的是非观念
: 计算机技术大多数时候是一个binary world，没有较真的精神，也就无乐趣而言。老外
: 喜欢说 My Pleasure Is My Business。
: goodbug那个所谓的分布式分票算法，迄今为止似乎大多数网友都没看出其中的问题。
: 我被封发贴与此有关，当然我自省其中有我不冷静因素，但是我还要不吐不快。
: goodbug定义它的系统是延迟分票系统，不是彩票系统对吧？
|
a***n
发帖数: 538 | 6 但是两张票之间的冲突从所有能出的票来说并不大，分布事务也可以。非要用单机有点
抬杠了，最后还是一堆机器做预处理。
【在 L*****e 的大作中提到】
: 这强耦合数据和并行分布处理就是死敌啊。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
N********n
发帖数: 8363 | 7
耦合与分布本来就是对掐的吗。所以这里言必称"BIG DATA"的还是消停会
吧，一切取决于你的数据模型。一旦耦合起来啥DATA MODEL来分布也没戏。
【在 L*****e 的大作中提到】
: 这强耦合数据和并行分布处理就是死敌啊。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
L*****e
发帖数: 8347 | 8 他二位抬的就是这个0%出错率的杠，而且要用理论worst case来考量，机器2上一张联
票依赖机器1上的联票，机器3上的一张联票又依赖机器2上的那张联票，机器4上的一张
联票又依赖于机器3上的那张联票。。。worst case就是1000台机子上的票们都互相关
联。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 a***n 的大作中提到】
: 但是两张票之间的冲突从所有能出的票来说并不大，分布事务也可以。非要用单机有点
: 抬杠了，最后还是一堆机器做预处理。
|
w**z
发帖数: 8232 | 9 goodbug 一开始说的就是分表。不同目的地的车次不同的表。具体怎能分，看情况。同
理，C* message 也是分开的。
【在 n*****t 的大作中提到】
: 寄信人: TeacherWei (TW)
: 标 题: 搞技术的，要有起码的是非观念
: 发信站: 未名空间 (Sun Feb 9 13:47:45 2014)
: 来 源: 68.
: 搞技术的，要有起码的是非观念
: 计算机技术大多数时候是一个binary world，没有较真的精神，也就无乐趣而言。老外
: 喜欢说 My Pleasure Is My Business。
: goodbug那个所谓的分布式分票算法，迄今为止似乎大多数网友都没看出其中的问题。
: 我被封发贴与此有关，当然我自省其中有我不冷静因素，但是我还要不吐不快。
: goodbug定义它的系统是延迟分票系统，不是彩票系统对吧？
|
p***o
发帖数: 1252 | 10 100k/s那段不对，如果票不相关（不同车次），就无所谓先后，可以分布式处理。
票相关的时候（同一车次）才需要考虑先后，需要顺序处理的请求数会远小于100k/s。
这概念Lamport 30年前就说的很清楚了。
【在 n*****t 的大作中提到】
: 寄信人: TeacherWei (TW)
: 标 题: 搞技术的，要有起码的是非观念
: 发信站: 未名空间 (Sun Feb 9 13:47:45 2014)
: 来 源: 68.
: 搞技术的，要有起码的是非观念
: 计算机技术大多数时候是一个binary world，没有较真的精神，也就无乐趣而言。老外
: 喜欢说 My Pleasure Is My Business。
: goodbug那个所谓的分布式分票算法，迄今为止似乎大多数网友都没看出其中的问题。
: 我被封发贴与此有关，当然我自省其中有我不冷静因素，但是我还要不吐不快。
: goodbug定义它的系统是延迟分票系统，不是彩票系统对吧？
|
|
|
a***n
发帖数: 538 | 11 就是同一车次，票多的时候也可以分布处理的。
【在 p***o 的大作中提到】
: 100k/s那段不对，如果票不相关（不同车次），就无所谓先后，可以分布式处理。
: 票相关的时候（同一车次）才需要考虑先后，需要顺序处理的请求数会远小于100k/s。
: 这概念Lamport 30年前就说的很清楚了。
|
b*******g
发帖数: 603 | 12 每秒100万的单子，1000条线，3种类型，就是3000种完全不相干的排队。
就算不平均分布，热门线路硬座每秒1万－2万的单子过来也是个合理估计。
怎么会撑不出，太监完全没脑子。
【在 w**z 的大作中提到】
: goodbug 一开始说的就是分表。不同目的地的车次不同的表。具体怎能分，看情况。同
: 理，C* message 也是分开的。
|
w**z
发帖数: 8232 | 13 本来就这意思。
【在 p***o 的大作中提到】
: 100k/s那段不对，如果票不相关（不同车次），就无所谓先后，可以分布式处理。
: 票相关的时候（同一车次）才需要考虑先后，需要顺序处理的请求数会远小于100k/s。
: 这概念Lamport 30年前就说的很清楚了。
|
L*****e
发帖数: 8347 | 14 因为联票的原因，分表也分离不了数据耦合性。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 w**z 的大作中提到】
: goodbug 一开始说的就是分表。不同目的地的车次不同的表。具体怎能分，看情况。同
: 理，C* message 也是分开的。
|
L*****e
发帖数: 8347 | 15 因为联票，理论上所有票都是相关的了。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 p***o 的大作中提到】
: 100k/s那段不对，如果票不相关（不同车次），就无所谓先后，可以分布式处理。
: 票相关的时候（同一车次）才需要考虑先后，需要顺序处理的请求数会远小于100k/s。
: 这概念Lamport 30年前就说的很清楚了。
|
N********n
发帖数: 8363 | 16
不在乎先后就没有公平了。这种分布系统又回到买票看人品的老路上了。
【在 p***o 的大作中提到】
: 100k/s那段不对，如果票不相关（不同车次），就无所谓先后，可以分布式处理。
: 票相关的时候（同一车次）才需要考虑先后，需要顺序处理的请求数会远小于100k/s。
: 这概念Lamport 30年前就说的很清楚了。
|
M*****0
发帖数: 850 | 17 真奇怪，老魏又被关了你怎么还能用BETTERBUG发帖啊，你不是应该升级到bestbug了吗
？
MQ
【在 b*******g 的大作中提到】
: 每秒100万的单子，1000条线，3种类型，就是3000种完全不相干的排队。
: 就算不平均分布，热门线路硬座每秒1万－2万的单子过来也是个合理估计。
: 怎么会撑不出，太监完全没脑子。
|
a***n
发帖数: 538 | 18 分布计算可以达到一个1ms的精度，实际上只要1,2秒内出票，对公平性有什么影响？
【在 N********n 的大作中提到】
:
: 不在乎先后就没有公平了。这种分布系统又回到买票看人品的老路上了。
|
w**z
发帖数: 8232 | 19 老魏为啥啊？ 没他，不热闹。
【在 M*****0 的大作中提到】
: 真奇怪，老魏又被关了你怎么还能用BETTERBUG发帖啊，你不是应该升级到bestbug了吗
: ？
:
: MQ
|
w**z
发帖数: 8232 | 20 哪有绝对公平，两人一起提交,一个request 正好碰上一个网路阻塞，晚到了。公平吗？
【在 a***n 的大作中提到】
: 分布计算可以达到一个1ms的精度，实际上只要1,2秒内出票，对公平性有什么影响？
|
|
|
b*******g
发帖数: 603 | 21 哪里不在乎先后？当然是有先后的，说的是分布式处理的时候，丢包try后面的人上去
了，这种情况不能避免。
【在 N********n 的大作中提到】
:
: 不在乎先后就没有公平了。这种分布系统又回到买票看人品的老路上了。
|
N********n
发帖数: 8363 | 22
建议你们还是把人家数据拿来PROFILE一把再保证1、2秒出票吧。光那堆联
票耦合在一起我就不知道你们怎么分，你咋保证DISTRIBUTED TRANSACTION
尽量少？
【在 a***n 的大作中提到】
: 分布计算可以达到一个1ms的精度，实际上只要1,2秒内出票，对公平性有什么影响？
|
N********n
发帖数: 8363 | 23
在乎先后就需要一个CENTRALIZED的QUEUE。这个QUEUE是HOT SPOT没法SCALE
OUT，回到老魏的单机问题上了。
【在 b*******g 的大作中提到】
: 哪里不在乎先后？当然是有先后的，说的是分布式处理的时候，丢包try后面的人上去
: 了，这种情况不能避免。
|
a***n
发帖数: 538 | 24 这个没有具体数据我也讲不清楚。反正我觉得只有在同一车次票少的时候才有冲突，而
且一张联票里面多张票同时低票量情况的可能性很低。就算出现这种情况，然后按时间
戳重试。
【在 N********n 的大作中提到】
:
: 在乎先后就需要一个CENTRALIZED的QUEUE。这个QUEUE是HOT SPOT没法SCALE
: OUT，回到老魏的单机问题上了。
|
b*******g
发帖数: 603 | 25 关于出票有很多策略，一个绝对没问题的策略就是分票。所有票平分10分到十个数据库
服务器，怎么处理联票都没问题。
另外一种就是联票10%，你把10%的所有票放一数据库里，其他所有线路按线路分。最后
再合票。
总之只要不追求绝对的公平，分布式出票的办法很多。
别忘了我的系统里所有分布式出票只是为了降低延迟，不像太监的系统做不到实时就要
丢单子，这是本质的区别。
【在 N********n 的大作中提到】
:
: 在乎先后就需要一个CENTRALIZED的QUEUE。这个QUEUE是HOT SPOT没法SCALE
: OUT，回到老魏的单机问题上了。
|
n*****t
发帖数: 22014 | 26 实在忍不住了，还有这么扯淡的啊？
【在 b*******g 的大作中提到】
: 关于出票有很多策略，一个绝对没问题的策略就是分票。所有票平分10分到十个数据库
: 服务器，怎么处理联票都没问题。
: 另外一种就是联票10%，你把10%的所有票放一数据库里，其他所有线路按线路分。最后
: 再合票。
: 总之只要不追求绝对的公平，分布式出票的办法很多。
: 别忘了我的系统里所有分布式出票只是为了降低延迟，不像太监的系统做不到实时就要
: 丢单子，这是本质的区别。
|
c****3
发帖数: 10787 | 27 其实最简单的是按照地理，根据出发城市分数据库，联票每段都是不同的出发城市。北
京算是枢纽大站，还可以按照南站，北站细分数据库，肯定不会超过1亿人同时买北京
南站或北站出发的票。不繁忙的小城市还可以合成一个数据库。
不过双方都是为了捍卫自己的信仰，并不一定是为了找最优方案
【在 b*******g 的大作中提到】
: 关于出票有很多策略，一个绝对没问题的策略就是分票。所有票平分10分到十个数据库
: 服务器，怎么处理联票都没问题。
: 另外一种就是联票10%，你把10%的所有票放一数据库里，其他所有线路按线路分。最后
: 再合票。
: 总之只要不追求绝对的公平，分布式出票的办法很多。
: 别忘了我的系统里所有分布式出票只是为了降低延迟，不像太监的系统做不到实时就要
: 丢单子，这是本质的区别。
|
n*****t
发帖数: 22014 | 28 始发分别上海、北京，在武汉怎么转车？
【在 c****3 的大作中提到】
: 其实最简单的是按照地理，根据出发城市分数据库，联票每段都是不同的出发城市。北
: 京算是枢纽大站，还可以按照南站，北站细分数据库，肯定不会超过1亿人同时买北京
: 南站或北站出发的票。不繁忙的小城市还可以合成一个数据库。
: 不过双方都是为了捍卫自己的信仰，并不一定是为了找最优方案
|
L*****e
发帖数: 8347 | 29 先说方法一，怎么把请求分到十个数据库上去处理? 按时间顺序十个十个分布到是个数
据库上去?
一个数据库中的票卖完了，分到这个数据库的请求就失败了，但明明别的数据库里还有
票，算不算不公? 座位优化就更没法保证了。。。
再说方法二，10%的联票请求分到一个专门的数据库中去，这个给联票的专门数据库包
含所有车次的车票数据吧? 那么这个数据库怎么和其它为非联票的按车次分的数据库里
的车票数据sync?
【在 b*******g 的大作中提到】
: 关于出票有很多策略，一个绝对没问题的策略就是分票。所有票平分10分到十个数据库
: 服务器，怎么处理联票都没问题。
: 另外一种就是联票10%，你把10%的所有票放一数据库里，其他所有线路按线路分。最后
: 再合票。
: 总之只要不追求绝对的公平，分布式出票的办法很多。
: 别忘了我的系统里所有分布式出票只是为了降低延迟，不像太监的系统做不到实时就要
: 丢单子，这是本质的区别。
|
L*****e
发帖数: 8347 | 30 我感觉他说这两个方法时，思维暂时短路了。。。
【在 n*****t 的大作中提到】
: 实在忍不住了，还有这么扯淡的啊？
|
|
|
c****3
发帖数: 10787 | 31 我前面在goodbug的总结贴里提过这种方法
http://www.mitbbs.com/article_t1/Programming/31312299_0_1.html
转车的也要一段一段抢票。上海出发经过武汉的，在上海数据库里抢上海-武汉的票，
北京出发经过武汉的，在北京数据库里抢北京-武汉的票。抢不到，就不用抢下一段了
，需要重新计算路径。
【在 n*****t 的大作中提到】
: 始发分别上海、北京，在武汉怎么转车？
|
n*****t
发帖数: 22014 | 32 那按始发站分布数据库还是不解决问题
【在 c****3 的大作中提到】
: 我前面在goodbug的总结贴里提过这种方法
: http://www.mitbbs.com/article_t1/Programming/31312299_0_1.html
: 转车的也要一段一段抢票。上海出发经过武汉的，在上海数据库里抢上海-武汉的票，
: 北京出发经过武汉的，在北京数据库里抢北京-武汉的票。抢不到，就不用抢下一段了
: ，需要重新计算路径。
|
n*****t
发帖数: 22014 | 33 缺乏基本训练，算法、数据库设计、分布计算，样样稀松。哪天我整整 JAVA，说不定
他连这个都要抓瞎。
真不知道这个是不是老邱的马甲啊
【在 L*****e 的大作中提到】
: 我感觉他说这两个方法时，思维暂时短路了。。。
|
L*****e
发帖数: 8347 | 34 老邱是谁?
【在 n*****t 的大作中提到】
: 缺乏基本训练，算法、数据库设计、分布计算，样样稀松。哪天我整整 JAVA，说不定
: 他连这个都要抓瞎。
: 真不知道这个是不是老邱的马甲啊
|
c****3
发帖数: 10787 | 35 性能问题不就是因为大家在一个数据库里抢票引起的。按照始发站细分数据库，大家就
到不同数据库里抢票了。这也符合管理需要。武汉没有必要去关心和管理，不是从它那
里始发的火车车次。
【在 n*****t 的大作中提到】
: 那按始发站分布数据库还是不解决问题
|
n*****t
发帖数: 22014 | 36 军版名角
【在 L*****e 的大作中提到】
: 老邱是谁?
|
b*******s
发帖数: 5216 | 37 不严格按照时间，这个他说过了
如果严格按照时间，就是个串行系统，分布毫无意义
【在 n*****t 的大作中提到】
: 寄信人: TeacherWei (TW)
: 标 题: 搞技术的，要有起码的是非观念
: 发信站: 未名空间 (Sun Feb 9 13:47:45 2014)
: 来 源: 68.
: 搞技术的，要有起码的是非观念
: 计算机技术大多数时候是一个binary world，没有较真的精神，也就无乐趣而言。老外
: 喜欢说 My Pleasure Is My Business。
: goodbug那个所谓的分布式分票算法，迄今为止似乎大多数网友都没看出其中的问题。
: 我被封发贴与此有关，当然我自省其中有我不冷静因素，但是我还要不吐不快。
: goodbug定义它的系统是延迟分票系统，不是彩票系统对吧？
|
n*****t
发帖数: 22014 | 38 单一个车次不存在抢票，按次序来就是了，一个线程管一个车次，一台机子管几个车次
，前端分门别类发请求就是了。这也是古德八最原始的想法，3000 台机子搞定 12306
，拿钱走人。
实际情况有那么简单吗？联程、邻座，这些都要跨数据库或者线程或者服务器，怎么协
调调度，怎么避免活锁死锁？
【在 c****3 的大作中提到】
: 性能问题不就是因为大家在一个数据库里抢票引起的。按照始发站细分数据库，大家就
: 到不同数据库里抢票了。这也符合管理需要。武汉没有必要去关心和管理，不是从它那
: 里始发的火车车次。
|
b*******s
发帖数: 5216 | 39 平分负载很容易不平衡，比如第一个时间段都在第一个库里，第二个都在第二个库里。
。。
这设计糟糕得很
另外延迟和throughput显然是两个概念
【在 b*******g 的大作中提到】
: 关于出票有很多策略，一个绝对没问题的策略就是分票。所有票平分10分到十个数据库
: 服务器，怎么处理联票都没问题。
: 另外一种就是联票10%，你把10%的所有票放一数据库里，其他所有线路按线路分。最后
: 再合票。
: 总之只要不追求绝对的公平，分布式出票的办法很多。
: 别忘了我的系统里所有分布式出票只是为了降低延迟，不像太监的系统做不到实时就要
: 丢单子，这是本质的区别。
|
L*****e
发帖数: 8347 | 40 武汉不用管不是它那里始发的火车，但是售票系统不能不管，武汉数据库里票是否卖出
被它下游数据库中的票有无影响，也同时影响着它的上游数据库。。。
【在 c****3 的大作中提到】
: 性能问题不就是因为大家在一个数据库里抢票引起的。按照始发站细分数据库，大家就
: 到不同数据库里抢票了。这也符合管理需要。武汉没有必要去关心和管理，不是从它那
: 里始发的火车车次。
|
|
|
c****3
发帖数: 10787 | 41 不需要同时锁多个数据库。联程票按照经过的区段，一段一段锁相应始发城市的数据库
，搞定相应的票。所有区段的票都搞定，才算成功。有一段失败，就把前面锁定的区段
释放。跨不跨服务器无所谓。
12306
【在 n*****t 的大作中提到】
: 单一个车次不存在抢票，按次序来就是了，一个线程管一个车次，一台机子管几个车次
: ，前端分门别类发请求就是了。这也是古德八最原始的想法，3000 台机子搞定 12306
: ，拿钱走人。
: 实际情况有那么简单吗？联程、邻座，这些都要跨数据库或者线程或者服务器，怎么协
: 调调度，怎么避免活锁死锁？
|
a***n
发帖数: 538 | 42 这个不就是第二层transaction。这个和底层用计数器，第二层transaction没本质区别。
我觉得这个问题主要底层的数据结构设计保证冲突的情况不是cascading的，用计数器
和数据库没什么区别。
【在 c****3 的大作中提到】
: 不需要同时锁多个数据库。联程票按照经过的区段，一段一段锁相应始发城市的数据库
: ，搞定相应的票。所有区段的票都搞定，才算成功。有一段失败，就把前面锁定的区段
: 释放。跨不跨服务器无所谓。
:
: 12306
|
c****3
发帖数: 10787 | 43 象北京到广州，经过武汉的直达高铁。中间虽然短停武汉，能上多少人，肯定是预先定
好的。以后根据情况在动态调配。
不可能像程序员想的那样是公平算法一起抢票的，肯定是人工管理和动态程序调配结合
的。那种自动分配算法在实际情况里没有意义。
否则有票贩子，一下把武汉到广州的票都抢走，北京到广州的高铁票还怎么卖。
所以从武汉出发的票有多少，肯定在发售之前都知道了。最多到售票后期发现上端有空
余票，武汉出发票紧张，再手工调配一些过来。
【在 L*****e 的大作中提到】
: 武汉不用管不是它那里始发的火车，但是售票系统不能不管，武汉数据库里票是否卖出
: 被它下游数据库中的票有无影响，也同时影响着它的上游数据库。。。
|
L*****e
发帖数: 8347 | 44 早就说了，两位都已经不是从具体需求来解决具体问题了，而是用理论worst case来抬
杠了。。。
【在 c****3 的大作中提到】
: 象北京到广州，经过武汉的直达高铁。中间虽然短停武汉，能上多少人，肯定是预先定
: 好的。以后根据情况在动态调配。
: 不可能像程序员想的那样是公平算法一起抢票的，肯定是人工管理和动态程序调配结合
: 的。那种自动分配算法在实际情况里没有意义。
: 否则有票贩子，一下把武汉到广州的票都抢走，北京到广州的高铁票还怎么卖。
: 所以从武汉出发的票有多少，肯定在发售之前都知道了。最多到售票后期发现上端有空
: 余票，武汉出发票紧张，再手工调配一些过来。
|
a***n
发帖数: 538 | 45 其实这个worst case也有问题的。因为冲突其实和并行度有关，单线程显然没有冲突，
这个worst case显然是按照所有request同时算的，但是如果只有有限的机器并行处理
，这个worst case就不一定成立了。
【在 L*****e 的大作中提到】
: 早就说了，两位都已经不是从具体需求来解决具体问题了，而是用理论worst case来抬
: 杠了。。。
|
c****3
发帖数: 10787 | 46 是啊，理论和实际根本什么相似性。
我相信铁道部肯定是用过往历史数据，已经预先分配好区间票的数量了。如果太热门，
就会加开直达车次。而且肯定很多都是人工干预的，不是拿程序算的，因为涉及车站之
间的利益，需要协调的。
【在 L*****e 的大作中提到】
: 早就说了，两位都已经不是从具体需求来解决具体问题了，而是用理论worst case来抬
: 杠了。。。
|
a****i
发帖数: 1182 | 47 草，讨论技术，动不动就人肉别人，骂人家人，问候人父母...居然叫别人有是非观念
尼马，知道无耻两个字怎么写的不？ |
e**o
发帖数: 5509 | 48 嗯。版上这些程序员总想用技术手段解决策略，政策，政治问题。
就是风马牛不相及。程序就是干活的，是工具。不能做决定，做判断。
【在 c****3 的大作中提到】
: 象北京到广州，经过武汉的直达高铁。中间虽然短停武汉，能上多少人，肯定是预先定
: 好的。以后根据情况在动态调配。
: 不可能像程序员想的那样是公平算法一起抢票的，肯定是人工管理和动态程序调配结合
: 的。那种自动分配算法在实际情况里没有意义。
: 否则有票贩子，一下把武汉到广州的票都抢走，北京到广州的高铁票还怎么卖。
: 所以从武汉出发的票有多少，肯定在发售之前都知道了。最多到售票后期发现上端有空
: 余票，武汉出发票紧张，再手工调配一些过来。
|
T********i
发帖数: 2416 | 49 矛盾么？
实时期搭好了，想做预定的加延迟。
想打击票贩子在上层做手脚。captcha验证，甚至IP检查，行为分析，身份证和银行帐
号追踪，抓到后该杀该判随意。
这些跟技术有什么矛盾的？一个技术，要能高频交易，电子商务，工业控制，武器系统
都能做才算是好技术。
【在 e**o 的大作中提到】
: 嗯。版上这些程序员总想用技术手段解决策略，政策，政治问题。
: 就是风马牛不相及。程序就是干活的，是工具。不能做决定，做判断。
|
f****4
发帖数: 1359 | 50 gb给的是为了支持短时间的抢票。严格按时间先后是做不到的。
但这个严格的公平其实也没必要，只要和人命没关系的，然后客户还不知道有不公平的
，不公平也没啥。
【在 b*******s 的大作中提到】
: 不严格按照时间，这个他说过了
: 如果严格按照时间，就是个串行系统，分布毫无意义
|
|
|
f****4
发帖数: 1359 | 51 我提过这个的
现在国内做数据分析的已经可以很好的完成这些决策支持了
【在 c****3 的大作中提到】
: 是啊，理论和实际根本什么相似性。
: 我相信铁道部肯定是用过往历史数据，已经预先分配好区间票的数量了。如果太热门，
: 就会加开直达车次。而且肯定很多都是人工干预的，不是拿程序算的，因为涉及车站之
: 间的利益，需要协调的。
|
f****4
发帖数: 1359 | 52 人品问题～
【在 a****i 的大作中提到】
: 草，讨论技术，动不动就人肉别人，骂人家人，问候人父母...居然叫别人有是非观念
: 尼马，知道无耻两个字怎么写的不？
|
e**o
发帖数: 5509 | 53 你在做skynet.....
这么干，连当领导的都成摆设了。
【在 T********i 的大作中提到】
: 矛盾么？
: 实时期搭好了，想做预定的加延迟。
: 想打击票贩子在上层做手脚。captcha验证，甚至IP检查，行为分析，身份证和银行帐
: 号追踪，抓到后该杀该判随意。
: 这些跟技术有什么矛盾的？一个技术，要能高频交易，电子商务，工业控制，武器系统
: 都能做才算是好技术。
|
