w*d
2 楼
谢谢。。。
T*i
3 楼
除了古德霸以外。
都报个名上来,让大家看看。
都报个名上来,让大家看看。
M*n
4 楼
用那三种颜色比较好?
俺用了488, 594和405
405的信号很弱的说。
谢谢
俺用了488, 594和405
405的信号很弱的说。
谢谢
p*4
5 楼
要英文简历。我给我爹准备了中文简历,结果vo看了一眼就说为什么没有英文的, 中文
的不行。可能是因为他中文不行,看不懂这个专业是干吗的。。。。。
★ Sent from iPhone App: iReader Mitbbs Lite 7.39
的不行。可能是因为他中文不行,看不懂这个专业是干吗的。。。。。
★ Sent from iPhone App: iReader Mitbbs Lite 7.39
x*4
6 楼
我的也是类似。似乎多出的这部分刚好和软件占的空间一样
h*b
7 楼
平心而论,古德霸提出的架构的确更容易让人接受。 毕竟现在大规模网站都是那么做
的。其实古德霸从投资到技术到篮球贴,给我的感觉就好像Amazon上销量排名最高的东
西一样,基本上都是大流,很少见他爆冷门的。 就算不是最优,你跟着他走基本上不
用担心会被坑。
您的架构,不是说不行,但至少在互联网很少见到。 众人皆梦我独醒,赵策这些人扣
上过时的帽子也是可以理解。
说到底就是成王败寇,古德霸好歹是netflix, 代表的就是当代最主流的架构。 您的
交易平台,还有新的家居平台要是出了名了,立刻就碾压板上所有不同意见了。
的。其实古德霸从投资到技术到篮球贴,给我的感觉就好像Amazon上销量排名最高的东
西一样,基本上都是大流,很少见他爆冷门的。 就算不是最优,你跟着他走基本上不
用担心会被坑。
您的架构,不是说不行,但至少在互联网很少见到。 众人皆梦我独醒,赵策这些人扣
上过时的帽子也是可以理解。
说到底就是成王败寇,古德霸好歹是netflix, 代表的就是当代最主流的架构。 您的
交易平台,还有新的家居平台要是出了名了,立刻就碾压板上所有不同意见了。
T*i
11 楼
我何时在乎过碾压本版的不同意见?
我是被人无中生有追着骂了两年多,找回一个公道而已。
我真不在乎什么不同意见。不能容忍的是无耻而已。
至于什么架构,版上见过世面也不少。没见过世面大多也不会不要廉耻。
我是被人无中生有追着骂了两年多,找回一个公道而已。
我真不在乎什么不同意见。不能容忍的是无耻而已。
至于什么架构,版上见过世面也不少。没见过世面大多也不会不要廉耻。
F*6
12 楼
我喜欢405,488,561,633
s*o
13 楼
可能是备份的问题,比如你avplayer里面放了3g电影,二你的avplayer是JB后装的盗版
g*u
14 楼
netflix是一个媒体公司,技术做得好坏有很大的余地,做技术的成本控制也有很大的
余地,用netflix的搞法,去别的公司未必能行得通。
特定于这次12306的架构,你的观点我同意。就是如果自己技术水平一般且没什么
判断力,走goodbug的套路比走HFT的套路更靠谱。
【在 h******b 的大作中提到】
: 平心而论,古德霸提出的架构的确更容易让人接受。 毕竟现在大规模网站都是那么做
: 的。其实古德霸从投资到技术到篮球贴,给我的感觉就好像Amazon上销量排名最高的东
: 西一样,基本上都是大流,很少见他爆冷门的。 就算不是最优,你跟着他走基本上不
: 用担心会被坑。
: 您的架构,不是说不行,但至少在互联网很少见到。 众人皆梦我独醒,赵策这些人扣
: 上过时的帽子也是可以理解。
: 说到底就是成王败寇,古德霸好歹是netflix, 代表的就是当代最主流的架构。 您的
: 交易平台,还有新的家居平台要是出了名了,立刻就碾压板上所有不同意见了。
余地,用netflix的搞法,去别的公司未必能行得通。
特定于这次12306的架构,你的观点我同意。就是如果自己技术水平一般且没什么
判断力,走goodbug的套路比走HFT的套路更靠谱。
【在 h******b 的大作中提到】
: 平心而论,古德霸提出的架构的确更容易让人接受。 毕竟现在大规模网站都是那么做
: 的。其实古德霸从投资到技术到篮球贴,给我的感觉就好像Amazon上销量排名最高的东
: 西一样,基本上都是大流,很少见他爆冷门的。 就算不是最优,你跟着他走基本上不
: 用担心会被坑。
: 您的架构,不是说不行,但至少在互联网很少见到。 众人皆梦我独醒,赵策这些人扣
: 上过时的帽子也是可以理解。
: 说到底就是成王败寇,古德霸好歹是netflix, 代表的就是当代最主流的架构。 您的
: 交易平台,还有新的家居平台要是出了名了,立刻就碾压板上所有不同意见了。
M*n
15 楼
找不到561,
只找到了Alex 568
只找到了Alex 568
M*n
23 楼
thansk.
明天买个568
准备488 568 647
明天买个568
准备488 568 647
k*0
24 楼
你没看懂他们的设计, 两个都能做, 但是老魏的方按简洁实用, 要好很多。
【在 h******b 的大作中提到】
: 平心而论,古德霸提出的架构的确更容易让人接受。 毕竟现在大规模网站都是那么做
: 的。其实古德霸从投资到技术到篮球贴,给我的感觉就好像Amazon上销量排名最高的东
: 西一样,基本上都是大流,很少见他爆冷门的。 就算不是最优,你跟着他走基本上不
: 用担心会被坑。
: 您的架构,不是说不行,但至少在互联网很少见到。 众人皆梦我独醒,赵策这些人扣
: 上过时的帽子也是可以理解。
: 说到底就是成王败寇,古德霸好歹是netflix, 代表的就是当代最主流的架构。 您的
: 交易平台,还有新的家居平台要是出了名了,立刻就碾压板上所有不同意见了。
【在 h******b 的大作中提到】
: 平心而论,古德霸提出的架构的确更容易让人接受。 毕竟现在大规模网站都是那么做
: 的。其实古德霸从投资到技术到篮球贴,给我的感觉就好像Amazon上销量排名最高的东
: 西一样,基本上都是大流,很少见他爆冷门的。 就算不是最优,你跟着他走基本上不
: 用担心会被坑。
: 您的架构,不是说不行,但至少在互联网很少见到。 众人皆梦我独醒,赵策这些人扣
: 上过时的帽子也是可以理解。
: 说到底就是成王败寇,古德霸好歹是netflix, 代表的就是当代最主流的架构。 您的
: 交易平台,还有新的家居平台要是出了名了,立刻就碾压板上所有不同意见了。
V*n
25 楼
488, 555, 647 plus DAPI
Invitrogen has them
Invitrogen has them
z*e
28 楼
快给我拉倒,老年人别丢人了
单线程你做个屁transaction
要多傻叉才会把你的破烂当回事啊
单线程你做个屁transaction
要多傻叉才会把你的破烂当回事啊
k*n
33 楼
刚休假回来。 我之前好像有一些关于赌约的回复被删了,考古了会。
姓wei的po出了东西,大致看了下代码和协议, 我觉得就是做了一个找票的toy。 单机
,暴力查找, 无容灾备份的一个纯跑在mem上的程序, 各种列出来的条件似乎是特意
回避了真正的瓶颈。 也可能有什么特殊的地方我水平不够没看出来,c++我不是很熟悉
, 但这离单机版的web service都不是, 差远了。
鉴于赌约就是如此, 我向姓wei的表示认输罢, 之前喷姓wei的应下赌约就是看不惯之
前报告hr和只说不做的被打脸了动不动新开帖attention whore那一套做派, 恶心死了
。 我没怎么仔细看赌约条款也没在乎里边有没有陷阱以及并不care输赢, 你能po出东
西就行, 即便最后是玩具至少也比之前那一套做派好得多。
赌约我认输,不过赌约之外这还是个toy, 单机server没有资格谈架构。
姓wei的po出了东西,大致看了下代码和协议, 我觉得就是做了一个找票的toy。 单机
,暴力查找, 无容灾备份的一个纯跑在mem上的程序, 各种列出来的条件似乎是特意
回避了真正的瓶颈。 也可能有什么特殊的地方我水平不够没看出来,c++我不是很熟悉
, 但这离单机版的web service都不是, 差远了。
鉴于赌约就是如此, 我向姓wei的表示认输罢, 之前喷姓wei的应下赌约就是看不惯之
前报告hr和只说不做的被打脸了动不动新开帖attention whore那一套做派, 恶心死了
。 我没怎么仔细看赌约条款也没在乎里边有没有陷阱以及并不care输赢, 你能po出东
西就行, 即便最后是玩具至少也比之前那一套做派好得多。
赌约我认输,不过赌约之外这还是个toy, 单机server没有资格谈架构。
k*n
36 楼
就你offer个屁呀。
要不是你撒泼打滚说必须3个人都接赌约才写出这个toy的模样我才懒得接,另外一个人
的是linear scalability你到底接了没有我就不记得了, 你自己立了赌约急着催别人
接到底为什么你还不知道吗? 要不应着你刻意设计的单机版赌约你就尽着做attension
whore了, 哪个帖子没打脸哪个帖子重新开。
我比你年轻,但我rp比你好得多, 就算你做的是toy我也认输了。 我可不像你时时刻
刻在坛子里。
bye, toyman。
【在 T********i 的大作中提到】
: 当时我offer了两次,你们一起上,同样条件,能做到1M/s,连网络服务都不用,就算
: 你们赢。
: 你当时没卵子,现在咋有脸上来?你的脸皮和廉耻都被狗吃了?
: 你FB的。我记得你。
T*i
37 楼
d*a
46 楼
我同意这两个观点。老魏的做法,属于非常传统,六七十年代mainframe上的做法。对
于这个具体的问题,传统做法可以比分布式的做法效率高得多,一台机器可以抵过成千
上万台机器(如果不是更多)。但另一方面,国人掐架不应该搞得这么厉害。技术讨论
,就事论事,对和错都可以学到东西。不要人参公鸡,没什么意思。
【在 g********n 的大作中提到】
: 我是古德吧的扇子, 但就具体问题而言,我认为老魏是这些问题的专家,古派甚至
: 都没有搞清楚问题的实质。
: 在这里做一个标记就是关键问题,业务逻辑再复杂, 都可以推到别的core,可以有
: 各种方案。古派对这些问题甚至没有数量级的概念, 不认输是不行的。做java的人不
: 一定知道如何把thread安排到不同的指定的core,这没关系,但要在这些领域与老
: 魏较量,你们实在赢不了。
: 当然工业界一般用你们的方案,这有别的原因。
: 老魏也别得势不饶人,你的水平有CODE作证了,不必多说了:)
于这个具体的问题,传统做法可以比分布式的做法效率高得多,一台机器可以抵过成千
上万台机器(如果不是更多)。但另一方面,国人掐架不应该搞得这么厉害。技术讨论
,就事论事,对和错都可以学到东西。不要人参公鸡,没什么意思。
【在 g********n 的大作中提到】
: 我是古德吧的扇子, 但就具体问题而言,我认为老魏是这些问题的专家,古派甚至
: 都没有搞清楚问题的实质。
: 在这里做一个标记就是关键问题,业务逻辑再复杂, 都可以推到别的core,可以有
: 各种方案。古派对这些问题甚至没有数量级的概念, 不认输是不行的。做java的人不
: 一定知道如何把thread安排到不同的指定的core,这没关系,但要在这些领域与老
: 魏较量,你们实在赢不了。
: 当然工业界一般用你们的方案,这有别的原因。
: 老魏也别得势不饶人,你的水平有CODE作证了,不必多说了:)
a*i
52 楼
我就说这个赌只不过证明了后面的确没有了。就是一个计数器。连他自已说的“全国一
盘棋”都没有,联票是必须的。
【在 k******n 的大作中提到】
: 刚休假回来。 我之前好像有一些关于赌约的回复被删了,考古了会。
: 姓wei的po出了东西,大致看了下代码和协议, 我觉得就是做了一个找票的toy。 单机
: ,暴力查找, 无容灾备份的一个纯跑在mem上的程序, 各种列出来的条件似乎是特意
: 回避了真正的瓶颈。 也可能有什么特殊的地方我水平不够没看出来,c++我不是很熟悉
: , 但这离单机版的web service都不是, 差远了。
: 鉴于赌约就是如此, 我向姓wei的表示认输罢, 之前喷姓wei的应下赌约就是看不惯之
: 前报告hr和只说不做的被打脸了动不动新开帖attention whore那一套做派, 恶心死了
: 。 我没怎么仔细看赌约条款也没在乎里边有没有陷阱以及并不care输赢, 你能po出东
: 西就行, 即便最后是玩具至少也比之前那一套做派好得多。
: 赌约我认输,不过赌约之外这还是个toy, 单机server没有资格谈架构。
盘棋”都没有,联票是必须的。
【在 k******n 的大作中提到】
: 刚休假回来。 我之前好像有一些关于赌约的回复被删了,考古了会。
: 姓wei的po出了东西,大致看了下代码和协议, 我觉得就是做了一个找票的toy。 单机
: ,暴力查找, 无容灾备份的一个纯跑在mem上的程序, 各种列出来的条件似乎是特意
: 回避了真正的瓶颈。 也可能有什么特殊的地方我水平不够没看出来,c++我不是很熟悉
: , 但这离单机版的web service都不是, 差远了。
: 鉴于赌约就是如此, 我向姓wei的表示认输罢, 之前喷姓wei的应下赌约就是看不惯之
: 前报告hr和只说不做的被打脸了动不动新开帖attention whore那一套做派, 恶心死了
: 。 我没怎么仔细看赌约条款也没在乎里边有没有陷阱以及并不care输赢, 你能po出东
: 西就行, 即便最后是玩具至少也比之前那一套做派好得多。
: 赌约我认输,不过赌约之外这还是个toy, 单机server没有资格谈架构。
a*i
55 楼
qxc的方案我当然赞同啊,有前有后,完整的一套
弄个计数器就唬倒一片也是挺奇怪的
前端的路线选择,换车,后面的付款出票;中间不买了,票怎么返回……
谈的是12306的方案是不?
你要是追一年多前的,TW开始号称是web服务器也放在这个单机上
“最佳方案,没有之一”的那种
【在 n*******7 的大作中提到】
: 说别人“后面没有”的能不能先拿出个前面有后面有的方案?
: 这方面qxc做得很好。他拿出了一个方案。我们就可以具体分析讨论,共同学习提高。
: 请aaaiii (酱爆)先说说是否赞同qxc的方案,是不是这个方案前面后面都有了。如果不
: 是,自己有何补充,还是可以另外拿出一套更好的?
: 先亮出一套自己觉得该有都有的方案来与老魏的code比较,再说老魏的code什么没有
: 才有意义。
弄个计数器就唬倒一片也是挺奇怪的
前端的路线选择,换车,后面的付款出票;中间不买了,票怎么返回……
谈的是12306的方案是不?
你要是追一年多前的,TW开始号称是web服务器也放在这个单机上
“最佳方案,没有之一”的那种
【在 n*******7 的大作中提到】
: 说别人“后面没有”的能不能先拿出个前面有后面有的方案?
: 这方面qxc做得很好。他拿出了一个方案。我们就可以具体分析讨论,共同学习提高。
: 请aaaiii (酱爆)先说说是否赞同qxc的方案,是不是这个方案前面后面都有了。如果不
: 是,自己有何补充,还是可以另外拿出一套更好的?
: 先亮出一套自己觉得该有都有的方案来与老魏的code比较,再说老魏的code什么没有
: 才有意义。
n*7
56 楼
按你的意见老魏的方案只是个计数器。那么你说说qxc方案里的5000个db
是不是计数器?
我们在qxc帖子里已经详细讨论比较了。老魏的方案其实就是db实现的
优化版,功能和scalability完全相同,除了更快没有区别。
你同意这个结论吗?如果不同意请说出来它们有什么不同,到底有什么地方qxc的db
做到而老魏的计数器没做到的。
如果同意,那你是在说qxc那5000个db也只是个计数器?你看qxc答应不答应。:)
【在 a****i 的大作中提到】
: qxc的方案我当然赞同啊,有前有后,完整的一套
: 弄个计数器就唬倒一片也是挺奇怪的
: 前端的路线选择,换车,后面的付款出票;中间不买了,票怎么返回……
: 谈的是12306的方案是不?
: 你要是追一年多前的,TW开始号称是web服务器也放在这个单机上
: “最佳方案,没有之一”的那种
是不是计数器?
我们在qxc帖子里已经详细讨论比较了。老魏的方案其实就是db实现的
优化版,功能和scalability完全相同,除了更快没有区别。
你同意这个结论吗?如果不同意请说出来它们有什么不同,到底有什么地方qxc的db
做到而老魏的计数器没做到的。
如果同意,那你是在说qxc那5000个db也只是个计数器?你看qxc答应不答应。:)
【在 a****i 的大作中提到】
: qxc的方案我当然赞同啊,有前有后,完整的一套
: 弄个计数器就唬倒一片也是挺奇怪的
: 前端的路线选择,换车,后面的付款出票;中间不买了,票怎么返回……
: 谈的是12306的方案是不?
: 你要是追一年多前的,TW开始号称是web服务器也放在这个单机上
: “最佳方案,没有之一”的那种
n*7
57 楼
再来讨论“后面”。:)
先探讨一下在qxc方案里什么是关键核心部分。应该不是web界面,不是对5000 后端db
分发锁票请求的中间服务器,而就是那存着所有余票的找票锁票的5000 后端 db。这应该
没有什么异议吧?
老魏的code直接就是那5000 db的drop-in replacement,以高得多的效率完成同样的功
能。 你说qxc 方案是完整的一套。那么老魏code 加上 qxc 方案去掉5000 db后的其它
非关键外围逻辑,是不是就是完整的一套?
所以,老魏code就是实现了qxc的12306的方案的关键核心部分。后面就是qxc方案里的
那些外围逻辑。怎么能说后面没有了?
【在 a****i 的大作中提到】
: qxc的方案我当然赞同啊,有前有后,完整的一套
: 弄个计数器就唬倒一片也是挺奇怪的
: 前端的路线选择,换车,后面的付款出票;中间不买了,票怎么返回……
: 谈的是12306的方案是不?
: 你要是追一年多前的,TW开始号称是web服务器也放在这个单机上
: “最佳方案,没有之一”的那种
先探讨一下在qxc方案里什么是关键核心部分。应该不是web界面,不是对5000 后端db
分发锁票请求的中间服务器,而就是那存着所有余票的找票锁票的5000 后端 db。这应该
没有什么异议吧?
老魏的code直接就是那5000 db的drop-in replacement,以高得多的效率完成同样的功
能。 你说qxc 方案是完整的一套。那么老魏code 加上 qxc 方案去掉5000 db后的其它
非关键外围逻辑,是不是就是完整的一套?
所以,老魏code就是实现了qxc的12306的方案的关键核心部分。后面就是qxc方案里的
那些外围逻辑。怎么能说后面没有了?
【在 a****i 的大作中提到】
: qxc的方案我当然赞同啊,有前有后,完整的一套
: 弄个计数器就唬倒一片也是挺奇怪的
: 前端的路线选择,换车,后面的付款出票;中间不买了,票怎么返回……
: 谈的是12306的方案是不?
: 你要是追一年多前的,TW开始号称是web服务器也放在这个单机上
: “最佳方案,没有之一”的那种
d*a
58 楼
理解票务中央调度方案(老魏称之为抢票机)的关键是,票务调度并不参与ACID。票务
调度只是给一个预售票方案,实际售票还是由前端票务机和后端数据库机来完成。
有了票务调度,前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位
。如果在卖票过程中出了问题,因为数据库系统有ACID的支持,不会出现卖了票却没收
到钱,或者联票卖出了一段,另一段却拿不到座位的情况。
从系统设计角度来说,票务中央调度大大降低了后端数据库机的负担。在同等硬件下,
系统吞吐量大增。否则后端数据库机系统得做得很大,用非常多的机器才能满足查询和
预占空位的请求。票务调度是一个紧密耦合的计算任务,用一台机器集中来做,比用成
千上万台机器来做,效率要高得多。
我说的这个方案,和老魏的方案可能稍有(或没有)不同。我没有跟后来的争论,有些
细节不是很了解。两年前,这版上有不少人是支持票务调度的集中式处理方案的。这个
方案从总体上说,是不难理解的。吵成这个样子,实在是过了。
【在 a****i 的大作中提到】
: qxc的方案我当然赞同啊,有前有后,完整的一套
: 弄个计数器就唬倒一片也是挺奇怪的
: 前端的路线选择,换车,后面的付款出票;中间不买了,票怎么返回……
: 谈的是12306的方案是不?
: 你要是追一年多前的,TW开始号称是web服务器也放在这个单机上
: “最佳方案,没有之一”的那种
调度只是给一个预售票方案,实际售票还是由前端票务机和后端数据库机来完成。
有了票务调度,前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位
。如果在卖票过程中出了问题,因为数据库系统有ACID的支持,不会出现卖了票却没收
到钱,或者联票卖出了一段,另一段却拿不到座位的情况。
从系统设计角度来说,票务中央调度大大降低了后端数据库机的负担。在同等硬件下,
系统吞吐量大增。否则后端数据库机系统得做得很大,用非常多的机器才能满足查询和
预占空位的请求。票务调度是一个紧密耦合的计算任务,用一台机器集中来做,比用成
千上万台机器来做,效率要高得多。
我说的这个方案,和老魏的方案可能稍有(或没有)不同。我没有跟后来的争论,有些
细节不是很了解。两年前,这版上有不少人是支持票务调度的集中式处理方案的。这个
方案从总体上说,是不难理解的。吵成这个样子,实在是过了。
【在 a****i 的大作中提到】
: qxc的方案我当然赞同啊,有前有后,完整的一套
: 弄个计数器就唬倒一片也是挺奇怪的
: 前端的路线选择,换车,后面的付款出票;中间不买了,票怎么返回……
: 谈的是12306的方案是不?
: 你要是追一年多前的,TW开始号称是web服务器也放在这个单机上
: “最佳方案,没有之一”的那种
T*i
59 楼
咱俩说的基本一码事。
你看看好虫两年前发的帖子:《应该给魏大师发10个图灵奖》
http://www.mitbbs.com/article_t1/Programming/31287951_0_1.html
对单机核心和ACID冷嘲热讽。
这两年,我是一直被恩追着骂的。这么简单的道理,非要写代码。写了代码还有人不懂
,也是醉了。
【在 d***a 的大作中提到】
: 理解票务中央调度方案(老魏称之为抢票机)的关键是,票务调度并不参与ACID。票务
: 调度只是给一个预售票方案,实际售票还是由前端票务机和后端数据库机来完成。
: 有了票务调度,前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位
: 。如果在卖票过程中出了问题,因为数据库系统有ACID的支持,不会出现卖了票却没收
: 到钱,或者联票卖出了一段,另一段却拿不到座位的情况。
: 从系统设计角度来说,票务中央调度大大降低了后端数据库机的负担。在同等硬件下,
: 系统吞吐量大增。否则后端数据库机系统得做得很大,用非常多的机器才能满足查询和
: 预占空位的请求。票务调度是一个紧密耦合的计算任务,用一台机器集中来做,比用成
: 千上万台机器来做,效率要高得多。
: 我说的这个方案,和老魏的方案可能稍有(或没有)不同。我没有跟后来的争论,有些
你看看好虫两年前发的帖子:《应该给魏大师发10个图灵奖》
http://www.mitbbs.com/article_t1/Programming/31287951_0_1.html
对单机核心和ACID冷嘲热讽。
这两年,我是一直被恩追着骂的。这么简单的道理,非要写代码。写了代码还有人不懂
,也是醉了。
【在 d***a 的大作中提到】
: 理解票务中央调度方案(老魏称之为抢票机)的关键是,票务调度并不参与ACID。票务
: 调度只是给一个预售票方案,实际售票还是由前端票务机和后端数据库机来完成。
: 有了票务调度,前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位
: 。如果在卖票过程中出了问题,因为数据库系统有ACID的支持,不会出现卖了票却没收
: 到钱,或者联票卖出了一段,另一段却拿不到座位的情况。
: 从系统设计角度来说,票务中央调度大大降低了后端数据库机的负担。在同等硬件下,
: 系统吞吐量大增。否则后端数据库机系统得做得很大,用非常多的机器才能满足查询和
: 预占空位的请求。票务调度是一个紧密耦合的计算任务,用一台机器集中来做,比用成
: 千上万台机器来做,效率要高得多。
: 我说的这个方案,和老魏的方案可能稍有(或没有)不同。我没有跟后来的争论,有些
n*7
60 楼
很多人就是接受不了用一台机子集中做,认为是上个世纪的,不符合他们现代的分布式
理念。
【在 d***a 的大作中提到】
: 理解票务中央调度方案(老魏称之为抢票机)的关键是,票务调度并不参与ACID。票务
: 调度只是给一个预售票方案,实际售票还是由前端票务机和后端数据库机来完成。
: 有了票务调度,前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位
: 。如果在卖票过程中出了问题,因为数据库系统有ACID的支持,不会出现卖了票却没收
: 到钱,或者联票卖出了一段,另一段却拿不到座位的情况。
: 从系统设计角度来说,票务中央调度大大降低了后端数据库机的负担。在同等硬件下,
: 系统吞吐量大增。否则后端数据库机系统得做得很大,用非常多的机器才能满足查询和
: 预占空位的请求。票务调度是一个紧密耦合的计算任务,用一台机器集中来做,比用成
: 千上万台机器来做,效率要高得多。
: 我说的这个方案,和老魏的方案可能稍有(或没有)不同。我没有跟后来的争论,有些
理念。
【在 d***a 的大作中提到】
: 理解票务中央调度方案(老魏称之为抢票机)的关键是,票务调度并不参与ACID。票务
: 调度只是给一个预售票方案,实际售票还是由前端票务机和后端数据库机来完成。
: 有了票务调度,前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位
: 。如果在卖票过程中出了问题,因为数据库系统有ACID的支持,不会出现卖了票却没收
: 到钱,或者联票卖出了一段,另一段却拿不到座位的情况。
: 从系统设计角度来说,票务中央调度大大降低了后端数据库机的负担。在同等硬件下,
: 系统吞吐量大增。否则后端数据库机系统得做得很大,用非常多的机器才能满足查询和
: 预占空位的请求。票务调度是一个紧密耦合的计算任务,用一台机器集中来做,比用成
: 千上万台机器来做,效率要高得多。
: 我说的这个方案,和老魏的方案可能稍有(或没有)不同。我没有跟后来的争论,有些
a*i
62 楼
你说的是票务调度,而我说的是整个12306
12306是从查票到抢票到付款买票再加上退票。只有抢票快,就是最佳方案了?
你觉得分布式就不能做票务调度还是怎么的?我把票都load到redis里行不行?在redis
里做调度行不行?
用redis做replication,你要砸哪台机器?
前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位…
这不就是好虫和qxz的分布式设计嘛
我不知道你们怎么老想着会去查数据库。起码的cache概念能有吧。
卖票过程中出了问题,因为数据库系统有ACID的支持, 那不还是好虫他们的设计?
【在 d***a 的大作中提到】
: 理解票务中央调度方案(老魏称之为抢票机)的关键是,票务调度并不参与ACID。票务
: 调度只是给一个预售票方案,实际售票还是由前端票务机和后端数据库机来完成。
: 有了票务调度,前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位
: 。如果在卖票过程中出了问题,因为数据库系统有ACID的支持,不会出现卖了票却没收
: 到钱,或者联票卖出了一段,另一段却拿不到座位的情况。
: 从系统设计角度来说,票务中央调度大大降低了后端数据库机的负担。在同等硬件下,
: 系统吞吐量大增。否则后端数据库机系统得做得很大,用非常多的机器才能满足查询和
: 预占空位的请求。票务调度是一个紧密耦合的计算任务,用一台机器集中来做,比用成
: 千上万台机器来做,效率要高得多。
: 我说的这个方案,和老魏的方案可能稍有(或没有)不同。我没有跟后来的争论,有些
12306是从查票到抢票到付款买票再加上退票。只有抢票快,就是最佳方案了?
你觉得分布式就不能做票务调度还是怎么的?我把票都load到redis里行不行?在redis
里做调度行不行?
用redis做replication,你要砸哪台机器?
前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位…
这不就是好虫和qxz的分布式设计嘛
我不知道你们怎么老想着会去查数据库。起码的cache概念能有吧。
卖票过程中出了问题,因为数据库系统有ACID的支持, 那不还是好虫他们的设计?
【在 d***a 的大作中提到】
: 理解票务中央调度方案(老魏称之为抢票机)的关键是,票务调度并不参与ACID。票务
: 调度只是给一个预售票方案,实际售票还是由前端票务机和后端数据库机来完成。
: 有了票务调度,前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位
: 。如果在卖票过程中出了问题,因为数据库系统有ACID的支持,不会出现卖了票却没收
: 到钱,或者联票卖出了一段,另一段却拿不到座位的情况。
: 从系统设计角度来说,票务中央调度大大降低了后端数据库机的负担。在同等硬件下,
: 系统吞吐量大增。否则后端数据库机系统得做得很大,用非常多的机器才能满足查询和
: 预占空位的请求。票务调度是一个紧密耦合的计算任务,用一台机器集中来做,比用成
: 千上万台机器来做,效率要高得多。
: 我说的这个方案,和老魏的方案可能稍有(或没有)不同。我没有跟后来的争论,有些
d*a
63 楼
别这么激动...你这么做当然可以,机器资源投入足够大就行。这里只是做技术性讨论
,看哪一种方案效率高。
如前面所说,很多方案最终都可以达到结果,只不过效率不同。在公司里,很多时候并
不是以技术决定谁的方案会被使用,是看谁的power更大。一个低效的方案,多砸几十
倍的资金,有的时候也可行。但不是任何时候都可行,要看具体的问题,对性能的需要
有多大,等等。
象12306的问题,按他们现有的系统架构,我个人觉得,要保证春运时不崩溃,加几倍
甚至十倍的硬件投入,都不知道能不能保证。但从领导的角度来说,加硬件是最简单的
,并且可以让本部门的重要性进一步提高,也许是更好的办法。
至于你后面说的方案,并不是12306现有的系统架构吧。把查询和预占空位的功能从数
据库系统里拿出来,另外用一个分布式的构件来实现,当然可以。但是这个功能,用单
机来实现,在性能上绰绰有余,在实现上简单得多,也可靠得多,那为什么要用分布式
的做法呢?当然,如果你从哲学角度出发,一定要用分布式的做法,也是可以的,但这
并不意味着单机方案本身在技术上有什么问题。
redis
【在 a****i 的大作中提到】
: 你说的是票务调度,而我说的是整个12306
: 12306是从查票到抢票到付款买票再加上退票。只有抢票快,就是最佳方案了?
: 你觉得分布式就不能做票务调度还是怎么的?我把票都load到redis里行不行?在redis
: 里做调度行不行?
: 用redis做replication,你要砸哪台机器?
: 前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位…
: 这不就是好虫和qxz的分布式设计嘛
: 我不知道你们怎么老想着会去查数据库。起码的cache概念能有吧。
: 卖票过程中出了问题,因为数据库系统有ACID的支持, 那不还是好虫他们的设计?
,看哪一种方案效率高。
如前面所说,很多方案最终都可以达到结果,只不过效率不同。在公司里,很多时候并
不是以技术决定谁的方案会被使用,是看谁的power更大。一个低效的方案,多砸几十
倍的资金,有的时候也可行。但不是任何时候都可行,要看具体的问题,对性能的需要
有多大,等等。
象12306的问题,按他们现有的系统架构,我个人觉得,要保证春运时不崩溃,加几倍
甚至十倍的硬件投入,都不知道能不能保证。但从领导的角度来说,加硬件是最简单的
,并且可以让本部门的重要性进一步提高,也许是更好的办法。
至于你后面说的方案,并不是12306现有的系统架构吧。把查询和预占空位的功能从数
据库系统里拿出来,另外用一个分布式的构件来实现,当然可以。但是这个功能,用单
机来实现,在性能上绰绰有余,在实现上简单得多,也可靠得多,那为什么要用分布式
的做法呢?当然,如果你从哲学角度出发,一定要用分布式的做法,也是可以的,但这
并不意味着单机方案本身在技术上有什么问题。
redis
【在 a****i 的大作中提到】
: 你说的是票务调度,而我说的是整个12306
: 12306是从查票到抢票到付款买票再加上退票。只有抢票快,就是最佳方案了?
: 你觉得分布式就不能做票务调度还是怎么的?我把票都load到redis里行不行?在redis
: 里做调度行不行?
: 用redis做replication,你要砸哪台机器?
: 前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位…
: 这不就是好虫和qxz的分布式设计嘛
: 我不知道你们怎么老想着会去查数据库。起码的cache概念能有吧。
: 卖票过程中出了问题,因为数据库系统有ACID的支持, 那不还是好虫他们的设计?
T*i
64 楼
其实吧,我这个人确实说话比较直接。我也知道,这么大岁数了,不想改,也改不了了。
直接跟你讲,redis做调度不行。不服你就拿代码出来。给我们讲清楚,加一个redis有
啥用?能起什么正面作用?
我刚才讲了奥卡姆剃刀原则。如无必要,勿增实体。这个原则,我的IoT平台网站上就
有。
另外给你讲,我的方案,不知抢票快,查询更快,退票也是最快,没有之一。
至于付款,我不想说。该咋办咋办,这种能够无限scale out的,我懒的说。
redis
【在 a****i 的大作中提到】
: 你说的是票务调度,而我说的是整个12306
: 12306是从查票到抢票到付款买票再加上退票。只有抢票快,就是最佳方案了?
: 你觉得分布式就不能做票务调度还是怎么的?我把票都load到redis里行不行?在redis
: 里做调度行不行?
: 用redis做replication,你要砸哪台机器?
: 前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位…
: 这不就是好虫和qxz的分布式设计嘛
: 我不知道你们怎么老想着会去查数据库。起码的cache概念能有吧。
: 卖票过程中出了问题,因为数据库系统有ACID的支持, 那不还是好虫他们的设计?
直接跟你讲,redis做调度不行。不服你就拿代码出来。给我们讲清楚,加一个redis有
啥用?能起什么正面作用?
我刚才讲了奥卡姆剃刀原则。如无必要,勿增实体。这个原则,我的IoT平台网站上就
有。
另外给你讲,我的方案,不知抢票快,查询更快,退票也是最快,没有之一。
至于付款,我不想说。该咋办咋办,这种能够无限scale out的,我懒的说。
redis
【在 a****i 的大作中提到】
: 你说的是票务调度,而我说的是整个12306
: 12306是从查票到抢票到付款买票再加上退票。只有抢票快,就是最佳方案了?
: 你觉得分布式就不能做票务调度还是怎么的?我把票都load到redis里行不行?在redis
: 里做调度行不行?
: 用redis做replication,你要砸哪台机器?
: 前端票务机不用去后端数据库机做费时的查找,就能找到和预占据空位…
: 这不就是好虫和qxz的分布式设计嘛
: 我不知道你们怎么老想着会去查数据库。起码的cache概念能有吧。
: 卖票过程中出了问题,因为数据库系统有ACID的支持, 那不还是好虫他们的设计?
b*s
65 楼
还是老话,合格程序员得有三个本事
会造轮子
知道什么时候不造轮子
知道什么时候造轮子
不能偏执
会造轮子
知道什么时候不造轮子
知道什么时候造轮子
不能偏执
相关阅读
生物科学家们想过这个问题吗?是谁养活了中国人施一公最新演讲: 生命科学是21世纪最重要的学科 (转载)我最穷那几年常吃牛奶拌饭 (转载)艺术家的确更容易发疯:有创造性的人得精神分裂症的风险增加了征寻有意自己创业的合作伙伴我今天也和老板争了一把Credit现在的工作市场怎么样?匹兹堡大学医学院博士后招聘 (转载)paper help请问专家BIACORE问题求前辈们提供免疫学疫苗学相关领域审稿机会11公和颜宁证明了所难们自豪的高考状元和奥赛金牌就是joke (转让公司make conditional KO mouse strain (cre-loxp, C57Bl/6paper help生物创业paper help有感为什么人类无法组装出一个细胞?Re: 柴玲的不值得说和刘晓波的殖民说有本质不同 (转载)