Redian新闻
>
有没有了解baker tilly的朋友
avatar
p*r
2
在哪里都一样啊
avatar
n*t
3
寄信人: 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等人,你们明白了么?
avatar
g*8
4
同时收到Baker tilly 和 四大PWC的offer(tax associate), 主要纠结是开车到费城
上班问题(1个小时),家在Baker tilly 附近(10分钟),但担心这是小公司,客户
也都是中小客户,担心以后职业发展,请前辈指点,不胜感激!
avatar
L*e
5
哦,你已经转了,那我把我转的可以删了。。。

★ 发自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定义它的系统是延迟分票系统,不是彩票系统对吧?

avatar
g*8
6
自己顶一下
avatar
L*e
7
老魏别的都还不错,就是这个帖子里点名叫板的习惯可以稍微改改。从人情世故来讲,
不应伤及无辜,从斗争策略来讲,不要战线太宽最后疲于应付。。。

★ 发自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定义它的系统是延迟分票系统,不是彩票系统对吧?

avatar
l*n
8
好帖
avatar
L*e
9
这强耦合数据和并行分布处理就是死敌啊。。。

★ 发自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定义它的系统是延迟分票系统,不是彩票系统对吧?

avatar
a*n
10
但是两张票之间的冲突从所有能出的票来说并不大,分布事务也可以。非要用单机有点
抬杠了,最后还是一堆机器做预处理。

【在 L*****e 的大作中提到】
: 这强耦合数据和并行分布处理就是死敌啊。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
: ★ 发自iPhone App: ChineseWeb 8.2.2

avatar
N*n
11

耦合与分布本来就是对掐的吗。所以这里言必称"BIG DATA"的还是消停会
吧,一切取决于你的数据模型。一旦耦合起来啥DATA MODEL来分布也没戏。

【在 L*****e 的大作中提到】
: 这强耦合数据和并行分布处理就是死敌啊。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
: ★ 发自iPhone App: ChineseWeb 8.2.2

avatar
L*e
12
他二位抬的就是这个0%出错率的杠,而且要用理论worst case来考量,机器2上一张联
票依赖机器1上的联票,机器3上的一张联票又依赖机器2上的那张联票,机器4上的一张
联票又依赖于机器3上的那张联票。。。worst case就是1000台机子上的票们都互相关
联。。。

★ 发自iPhone App: ChineseWeb 8.2.2

【在 a***n 的大作中提到】
: 但是两张票之间的冲突从所有能出的票来说并不大,分布事务也可以。非要用单机有点
: 抬杠了,最后还是一堆机器做预处理。

avatar
w*z
13
goodbug 一开始说的就是分表。不同目的地的车次不同的表。具体怎能分,看情况。同
理,C* message 也是分开的。

【在 n*****t 的大作中提到】
: 寄信人: TeacherWei (TW)
: 标 题: 搞技术的,要有起码的是非观念
: 发信站: 未名空间 (Sun Feb 9 13:47:45 2014)
: 来 源: 68.
: 搞技术的,要有起码的是非观念
: 计算机技术大多数时候是一个binary world,没有较真的精神,也就无乐趣而言。老外
: 喜欢说 My Pleasure Is My Business。
: goodbug那个所谓的分布式分票算法,迄今为止似乎大多数网友都没看出其中的问题。
: 我被封发贴与此有关,当然我自省其中有我不冷静因素,但是我还要不吐不快。
: goodbug定义它的系统是延迟分票系统,不是彩票系统对吧?

avatar
p*o
14
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定义它的系统是延迟分票系统,不是彩票系统对吧?

avatar
a*n
15
就是同一车次,票多的时候也可以分布处理的。

【在 p***o 的大作中提到】
: 100k/s那段不对,如果票不相关(不同车次),就无所谓先后,可以分布式处理。
: 票相关的时候(同一车次)才需要考虑先后,需要顺序处理的请求数会远小于100k/s。
: 这概念Lamport 30年前就说的很清楚了。

avatar
b*g
16
每秒100万的单子,1000条线,3种类型,就是3000种完全不相干的排队。
就算不平均分布,热门线路硬座每秒1万-2万的单子过来也是个合理估计。
怎么会撑不出,太监完全没脑子。

【在 w**z 的大作中提到】
: goodbug 一开始说的就是分表。不同目的地的车次不同的表。具体怎能分,看情况。同
: 理,C* message 也是分开的。

avatar
w*z
17
本来就这意思。

【在 p***o 的大作中提到】
: 100k/s那段不对,如果票不相关(不同车次),就无所谓先后,可以分布式处理。
: 票相关的时候(同一车次)才需要考虑先后,需要顺序处理的请求数会远小于100k/s。
: 这概念Lamport 30年前就说的很清楚了。

avatar
L*e
18
因为联票的原因,分表也分离不了数据耦合性。。。

★ 发自iPhone App: ChineseWeb 8.2.2

【在 w**z 的大作中提到】
: goodbug 一开始说的就是分表。不同目的地的车次不同的表。具体怎能分,看情况。同
: 理,C* message 也是分开的。

avatar
L*e
19
因为联票,理论上所有票都是相关的了。。。

★ 发自iPhone App: ChineseWeb 8.2.2

【在 p***o 的大作中提到】
: 100k/s那段不对,如果票不相关(不同车次),就无所谓先后,可以分布式处理。
: 票相关的时候(同一车次)才需要考虑先后,需要顺序处理的请求数会远小于100k/s。
: 这概念Lamport 30年前就说的很清楚了。

avatar
N*n
20

不在乎先后就没有公平了。这种分布系统又回到买票看人品的老路上了。

【在 p***o 的大作中提到】
: 100k/s那段不对,如果票不相关(不同车次),就无所谓先后,可以分布式处理。
: 票相关的时候(同一车次)才需要考虑先后,需要顺序处理的请求数会远小于100k/s。
: 这概念Lamport 30年前就说的很清楚了。

avatar
M*0
21
真奇怪,老魏又被关了你怎么还能用BETTERBUG发帖啊,你不是应该升级到bestbug了吗


MQ

【在 b*******g 的大作中提到】
: 每秒100万的单子,1000条线,3种类型,就是3000种完全不相干的排队。
: 就算不平均分布,热门线路硬座每秒1万-2万的单子过来也是个合理估计。
: 怎么会撑不出,太监完全没脑子。

avatar
a*n
22
分布计算可以达到一个1ms的精度,实际上只要1,2秒内出票,对公平性有什么影响?

【在 N********n 的大作中提到】
:
: 不在乎先后就没有公平了。这种分布系统又回到买票看人品的老路上了。

avatar
w*z
23
老魏为啥啊? 没他,不热闹。

【在 M*****0 的大作中提到】
: 真奇怪,老魏又被关了你怎么还能用BETTERBUG发帖啊,你不是应该升级到bestbug了吗
: ?
:
: MQ

avatar
w*z
24
哪有绝对公平,两人一起提交,一个request 正好碰上一个网路阻塞,晚到了。公平吗?

【在 a***n 的大作中提到】
: 分布计算可以达到一个1ms的精度,实际上只要1,2秒内出票,对公平性有什么影响?
avatar
b*g
25
哪里不在乎先后?当然是有先后的,说的是分布式处理的时候,丢包try后面的人上去
了,这种情况不能避免。

【在 N********n 的大作中提到】
:
: 不在乎先后就没有公平了。这种分布系统又回到买票看人品的老路上了。

avatar
N*n
26

建议你们还是把人家数据拿来PROFILE一把再保证1、2秒出票吧。光那堆联
票耦合在一起我就不知道你们怎么分,你咋保证DISTRIBUTED TRANSACTION
尽量少?

【在 a***n 的大作中提到】
: 分布计算可以达到一个1ms的精度,实际上只要1,2秒内出票,对公平性有什么影响?
avatar
N*n
27

在乎先后就需要一个CENTRALIZED的QUEUE。这个QUEUE是HOT SPOT没法SCALE
OUT,回到老魏的单机问题上了。

【在 b*******g 的大作中提到】
: 哪里不在乎先后?当然是有先后的,说的是分布式处理的时候,丢包try后面的人上去
: 了,这种情况不能避免。

avatar
a*n
28
这个没有具体数据我也讲不清楚。反正我觉得只有在同一车次票少的时候才有冲突,而
且一张联票里面多张票同时低票量情况的可能性很低。就算出现这种情况,然后按时间
戳重试。

【在 N********n 的大作中提到】
:
: 在乎先后就需要一个CENTRALIZED的QUEUE。这个QUEUE是HOT SPOT没法SCALE
: OUT,回到老魏的单机问题上了。

avatar
b*g
29
关于出票有很多策略,一个绝对没问题的策略就是分票。所有票平分10分到十个数据库
服务器,怎么处理联票都没问题。
另外一种就是联票10%,你把10%的所有票放一数据库里,其他所有线路按线路分。最后
再合票。
总之只要不追求绝对的公平,分布式出票的办法很多。
别忘了我的系统里所有分布式出票只是为了降低延迟,不像太监的系统做不到实时就要
丢单子,这是本质的区别。

【在 N********n 的大作中提到】
:
: 在乎先后就需要一个CENTRALIZED的QUEUE。这个QUEUE是HOT SPOT没法SCALE
: OUT,回到老魏的单机问题上了。

avatar
n*t
30
实在忍不住了,还有这么扯淡的啊?

【在 b*******g 的大作中提到】
: 关于出票有很多策略,一个绝对没问题的策略就是分票。所有票平分10分到十个数据库
: 服务器,怎么处理联票都没问题。
: 另外一种就是联票10%,你把10%的所有票放一数据库里,其他所有线路按线路分。最后
: 再合票。
: 总之只要不追求绝对的公平,分布式出票的办法很多。
: 别忘了我的系统里所有分布式出票只是为了降低延迟,不像太监的系统做不到实时就要
: 丢单子,这是本质的区别。

avatar
c*3
31
其实最简单的是按照地理,根据出发城市分数据库,联票每段都是不同的出发城市。北
京算是枢纽大站,还可以按照南站,北站细分数据库,肯定不会超过1亿人同时买北京
南站或北站出发的票。不繁忙的小城市还可以合成一个数据库。
不过双方都是为了捍卫自己的信仰,并不一定是为了找最优方案

【在 b*******g 的大作中提到】
: 关于出票有很多策略,一个绝对没问题的策略就是分票。所有票平分10分到十个数据库
: 服务器,怎么处理联票都没问题。
: 另外一种就是联票10%,你把10%的所有票放一数据库里,其他所有线路按线路分。最后
: 再合票。
: 总之只要不追求绝对的公平,分布式出票的办法很多。
: 别忘了我的系统里所有分布式出票只是为了降低延迟,不像太监的系统做不到实时就要
: 丢单子,这是本质的区别。

avatar
n*t
32
始发分别上海、北京,在武汉怎么转车?

【在 c****3 的大作中提到】
: 其实最简单的是按照地理,根据出发城市分数据库,联票每段都是不同的出发城市。北
: 京算是枢纽大站,还可以按照南站,北站细分数据库,肯定不会超过1亿人同时买北京
: 南站或北站出发的票。不繁忙的小城市还可以合成一个数据库。
: 不过双方都是为了捍卫自己的信仰,并不一定是为了找最优方案

avatar
L*e
33
先说方法一,怎么把请求分到十个数据库上去处理? 按时间顺序十个十个分布到是个数
据库上去?
一个数据库中的票卖完了,分到这个数据库的请求就失败了,但明明别的数据库里还有
票,算不算不公? 座位优化就更没法保证了。。。
再说方法二,10%的联票请求分到一个专门的数据库中去,这个给联票的专门数据库包
含所有车次的车票数据吧? 那么这个数据库怎么和其它为非联票的按车次分的数据库里
的车票数据sync?

【在 b*******g 的大作中提到】
: 关于出票有很多策略,一个绝对没问题的策略就是分票。所有票平分10分到十个数据库
: 服务器,怎么处理联票都没问题。
: 另外一种就是联票10%,你把10%的所有票放一数据库里,其他所有线路按线路分。最后
: 再合票。
: 总之只要不追求绝对的公平,分布式出票的办法很多。
: 别忘了我的系统里所有分布式出票只是为了降低延迟,不像太监的系统做不到实时就要
: 丢单子,这是本质的区别。

avatar
L*e
34
我感觉他说这两个方法时,思维暂时短路了。。。

【在 n*****t 的大作中提到】
: 实在忍不住了,还有这么扯淡的啊?
avatar
c*3
35
我前面在goodbug的总结贴里提过这种方法
http://www.mitbbs.com/article_t1/Programming/31312299_0_1.html
转车的也要一段一段抢票。上海出发经过武汉的,在上海数据库里抢上海-武汉的票,
北京出发经过武汉的,在北京数据库里抢北京-武汉的票。抢不到,就不用抢下一段了
,需要重新计算路径。

【在 n*****t 的大作中提到】
: 始发分别上海、北京,在武汉怎么转车?
avatar
n*t
36
那按始发站分布数据库还是不解决问题

【在 c****3 的大作中提到】
: 我前面在goodbug的总结贴里提过这种方法
: http://www.mitbbs.com/article_t1/Programming/31312299_0_1.html
: 转车的也要一段一段抢票。上海出发经过武汉的,在上海数据库里抢上海-武汉的票,
: 北京出发经过武汉的,在北京数据库里抢北京-武汉的票。抢不到,就不用抢下一段了
: ,需要重新计算路径。

avatar
n*t
37
缺乏基本训练,算法、数据库设计、分布计算,样样稀松。哪天我整整 JAVA,说不定
他连这个都要抓瞎。
真不知道这个是不是老邱的马甲啊

【在 L*****e 的大作中提到】
: 我感觉他说这两个方法时,思维暂时短路了。。。
avatar
L*e
38
老邱是谁?

【在 n*****t 的大作中提到】
: 缺乏基本训练,算法、数据库设计、分布计算,样样稀松。哪天我整整 JAVA,说不定
: 他连这个都要抓瞎。
: 真不知道这个是不是老邱的马甲啊

avatar
c*3
39
性能问题不就是因为大家在一个数据库里抢票引起的。按照始发站细分数据库,大家就
到不同数据库里抢票了。这也符合管理需要。武汉没有必要去关心和管理,不是从它那
里始发的火车车次。

【在 n*****t 的大作中提到】
: 那按始发站分布数据库还是不解决问题
avatar
n*t
40
军版名角

【在 L*****e 的大作中提到】
: 老邱是谁?
avatar
b*s
41
不严格按照时间,这个他说过了
如果严格按照时间,就是个串行系统,分布毫无意义

【在 n*****t 的大作中提到】
: 寄信人: TeacherWei (TW)
: 标 题: 搞技术的,要有起码的是非观念
: 发信站: 未名空间 (Sun Feb 9 13:47:45 2014)
: 来 源: 68.
: 搞技术的,要有起码的是非观念
: 计算机技术大多数时候是一个binary world,没有较真的精神,也就无乐趣而言。老外
: 喜欢说 My Pleasure Is My Business。
: goodbug那个所谓的分布式分票算法,迄今为止似乎大多数网友都没看出其中的问题。
: 我被封发贴与此有关,当然我自省其中有我不冷静因素,但是我还要不吐不快。
: goodbug定义它的系统是延迟分票系统,不是彩票系统对吧?

avatar
n*t
42
单一个车次不存在抢票,按次序来就是了,一个线程管一个车次,一台机子管几个车次
,前端分门别类发请求就是了。这也是古德八最原始的想法,3000 台机子搞定 12306
,拿钱走人。
实际情况有那么简单吗?联程、邻座,这些都要跨数据库或者线程或者服务器,怎么协
调调度,怎么避免活锁死锁?

【在 c****3 的大作中提到】
: 性能问题不就是因为大家在一个数据库里抢票引起的。按照始发站细分数据库,大家就
: 到不同数据库里抢票了。这也符合管理需要。武汉没有必要去关心和管理,不是从它那
: 里始发的火车车次。

avatar
b*s
43
平分负载很容易不平衡,比如第一个时间段都在第一个库里,第二个都在第二个库里。
。。
这设计糟糕得很
另外延迟和throughput显然是两个概念

【在 b*******g 的大作中提到】
: 关于出票有很多策略,一个绝对没问题的策略就是分票。所有票平分10分到十个数据库
: 服务器,怎么处理联票都没问题。
: 另外一种就是联票10%,你把10%的所有票放一数据库里,其他所有线路按线路分。最后
: 再合票。
: 总之只要不追求绝对的公平,分布式出票的办法很多。
: 别忘了我的系统里所有分布式出票只是为了降低延迟,不像太监的系统做不到实时就要
: 丢单子,这是本质的区别。

avatar
L*e
44
武汉不用管不是它那里始发的火车,但是售票系统不能不管,武汉数据库里票是否卖出
被它下游数据库中的票有无影响,也同时影响着它的上游数据库。。。

【在 c****3 的大作中提到】
: 性能问题不就是因为大家在一个数据库里抢票引起的。按照始发站细分数据库,大家就
: 到不同数据库里抢票了。这也符合管理需要。武汉没有必要去关心和管理,不是从它那
: 里始发的火车车次。

avatar
c*3
45
不需要同时锁多个数据库。联程票按照经过的区段,一段一段锁相应始发城市的数据库
,搞定相应的票。所有区段的票都搞定,才算成功。有一段失败,就把前面锁定的区段
释放。跨不跨服务器无所谓。

12306

【在 n*****t 的大作中提到】
: 单一个车次不存在抢票,按次序来就是了,一个线程管一个车次,一台机子管几个车次
: ,前端分门别类发请求就是了。这也是古德八最原始的想法,3000 台机子搞定 12306
: ,拿钱走人。
: 实际情况有那么简单吗?联程、邻座,这些都要跨数据库或者线程或者服务器,怎么协
: 调调度,怎么避免活锁死锁?

avatar
a*n
46
这个不就是第二层transaction。这个和底层用计数器,第二层transaction没本质区别。
我觉得这个问题主要底层的数据结构设计保证冲突的情况不是cascading的,用计数器
和数据库没什么区别。

【在 c****3 的大作中提到】
: 不需要同时锁多个数据库。联程票按照经过的区段,一段一段锁相应始发城市的数据库
: ,搞定相应的票。所有区段的票都搞定,才算成功。有一段失败,就把前面锁定的区段
: 释放。跨不跨服务器无所谓。
:
: 12306

avatar
c*3
47
象北京到广州,经过武汉的直达高铁。中间虽然短停武汉,能上多少人,肯定是预先定
好的。以后根据情况在动态调配。
不可能像程序员想的那样是公平算法一起抢票的,肯定是人工管理和动态程序调配结合
的。那种自动分配算法在实际情况里没有意义。
否则有票贩子,一下把武汉到广州的票都抢走,北京到广州的高铁票还怎么卖。
所以从武汉出发的票有多少,肯定在发售之前都知道了。最多到售票后期发现上端有空
余票,武汉出发票紧张,再手工调配一些过来。

【在 L*****e 的大作中提到】
: 武汉不用管不是它那里始发的火车,但是售票系统不能不管,武汉数据库里票是否卖出
: 被它下游数据库中的票有无影响,也同时影响着它的上游数据库。。。

avatar
L*e
48
早就说了,两位都已经不是从具体需求来解决具体问题了,而是用理论worst case来抬
杠了。。。

【在 c****3 的大作中提到】
: 象北京到广州,经过武汉的直达高铁。中间虽然短停武汉,能上多少人,肯定是预先定
: 好的。以后根据情况在动态调配。
: 不可能像程序员想的那样是公平算法一起抢票的,肯定是人工管理和动态程序调配结合
: 的。那种自动分配算法在实际情况里没有意义。
: 否则有票贩子,一下把武汉到广州的票都抢走,北京到广州的高铁票还怎么卖。
: 所以从武汉出发的票有多少,肯定在发售之前都知道了。最多到售票后期发现上端有空
: 余票,武汉出发票紧张,再手工调配一些过来。

avatar
a*n
49
其实这个worst case也有问题的。因为冲突其实和并行度有关,单线程显然没有冲突,
这个worst case显然是按照所有request同时算的,但是如果只有有限的机器并行处理
,这个worst case就不一定成立了。

【在 L*****e 的大作中提到】
: 早就说了,两位都已经不是从具体需求来解决具体问题了,而是用理论worst case来抬
: 杠了。。。

avatar
c*3
50
是啊,理论和实际根本什么相似性。
我相信铁道部肯定是用过往历史数据,已经预先分配好区间票的数量了。如果太热门,
就会加开直达车次。而且肯定很多都是人工干预的,不是拿程序算的,因为涉及车站之
间的利益,需要协调的。

【在 L*****e 的大作中提到】
: 早就说了,两位都已经不是从具体需求来解决具体问题了,而是用理论worst case来抬
: 杠了。。。

avatar
a*i
51
草,讨论技术,动不动就人肉别人,骂人家人,问候人父母...居然叫别人有是非观念
尼马,知道无耻两个字怎么写的不?
avatar
e*o
52
嗯。版上这些程序员总想用技术手段解决策略,政策,政治问题。
就是风马牛不相及。程序就是干活的,是工具。不能做决定,做判断。

【在 c****3 的大作中提到】
: 象北京到广州,经过武汉的直达高铁。中间虽然短停武汉,能上多少人,肯定是预先定
: 好的。以后根据情况在动态调配。
: 不可能像程序员想的那样是公平算法一起抢票的,肯定是人工管理和动态程序调配结合
: 的。那种自动分配算法在实际情况里没有意义。
: 否则有票贩子,一下把武汉到广州的票都抢走,北京到广州的高铁票还怎么卖。
: 所以从武汉出发的票有多少,肯定在发售之前都知道了。最多到售票后期发现上端有空
: 余票,武汉出发票紧张,再手工调配一些过来。

avatar
T*i
53
矛盾么?
实时期搭好了,想做预定的加延迟。
想打击票贩子在上层做手脚。captcha验证,甚至IP检查,行为分析,身份证和银行帐
号追踪,抓到后该杀该判随意。
这些跟技术有什么矛盾的?一个技术,要能高频交易,电子商务,工业控制,武器系统
都能做才算是好技术。

【在 e**o 的大作中提到】
: 嗯。版上这些程序员总想用技术手段解决策略,政策,政治问题。
: 就是风马牛不相及。程序就是干活的,是工具。不能做决定,做判断。

avatar
f*4
54
gb给的是为了支持短时间的抢票。严格按时间先后是做不到的。
但这个严格的公平其实也没必要,只要和人命没关系的,然后客户还不知道有不公平的
,不公平也没啥。

【在 b*******s 的大作中提到】
: 不严格按照时间,这个他说过了
: 如果严格按照时间,就是个串行系统,分布毫无意义

avatar
f*4
55
我提过这个的
现在国内做数据分析的已经可以很好的完成这些决策支持了

【在 c****3 的大作中提到】
: 是啊,理论和实际根本什么相似性。
: 我相信铁道部肯定是用过往历史数据,已经预先分配好区间票的数量了。如果太热门,
: 就会加开直达车次。而且肯定很多都是人工干预的,不是拿程序算的,因为涉及车站之
: 间的利益,需要协调的。

avatar
f*4
56
人品问题~

【在 a****i 的大作中提到】
: 草,讨论技术,动不动就人肉别人,骂人家人,问候人父母...居然叫别人有是非观念
: 尼马,知道无耻两个字怎么写的不?

avatar
e*o
57
你在做skynet.....
这么干,连当领导的都成摆设了。

【在 T********i 的大作中提到】
: 矛盾么?
: 实时期搭好了,想做预定的加延迟。
: 想打击票贩子在上层做手脚。captcha验证,甚至IP检查,行为分析,身份证和银行帐
: 号追踪,抓到后该杀该判随意。
: 这些跟技术有什么矛盾的?一个技术,要能高频交易,电子商务,工业控制,武器系统
: 都能做才算是好技术。

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。