p*******r 发帖数: 123 | 1 我和魏老师和谷德宝都不认识, 不过看起来这一战是魏老师大胜
魏老师确实水平不错, 从底层架构到硬件都很了解, 虽然提出的方案朴素无华, 但
是非常solid, 可谓程序员里的乔峰。
谷德宝为代表的java马工, 不可谓不是高手, 有大项目的经验, 自己做过的东西也
很熟, 不过感觉是过于迷失于一堆堆的流行技术, 一开口就是C*, nosql, aws, 但是
计算机的根基不稳,就像偷练易筋经的鸠摩智, 高手一过招就破绽太多。 |
w**z 发帖数: 8232 | 2 你看懂了?就那魏老师的几十行code?显摆一下interlocked?
【在 p*******r 的大作中提到】 : 我和魏老师和谷德宝都不认识, 不过看起来这一战是魏老师大胜 : 魏老师确实水平不错, 从底层架构到硬件都很了解, 虽然提出的方案朴素无华, 但 : 是非常solid, 可谓程序员里的乔峰。 : 谷德宝为代表的java马工, 不可谓不是高手, 有大项目的经验, 自己做过的东西也 : 很熟, 不过感觉是过于迷失于一堆堆的流行技术, 一开口就是C*, nosql, aws, 但是 : 计算机的根基不稳,就像偷练易筋经的鸠摩智, 高手一过招就破绽太多。
|
g*****g 发帖数: 34805 | 3 拉到吧,就一个decrement再increment不atomic的基础都不懂,自己承认到最后几张票
不稳定,最后不得不上来一堆人给他打补丁。
【在 p*******r 的大作中提到】 : 我和魏老师和谷德宝都不认识, 不过看起来这一战是魏老师大胜 : 魏老师确实水平不错, 从底层架构到硬件都很了解, 虽然提出的方案朴素无华, 但 : 是非常solid, 可谓程序员里的乔峰。 : 谷德宝为代表的java马工, 不可谓不是高手, 有大项目的经验, 自己做过的东西也 : 很熟, 不过感觉是过于迷失于一堆堆的流行技术, 一开口就是C*, nosql, aws, 但是 : 计算机的根基不稳,就像偷练易筋经的鸠摩智, 高手一过招就破绽太多。
|
i**i 发帖数: 1500 | 4 嗯,就是也不知道阿庆嫂最后跟刁德一结婚没有.
【在 p*******r 的大作中提到】 : 我和魏老师和谷德宝都不认识, 不过看起来这一战是魏老师大胜 : 魏老师确实水平不错, 从底层架构到硬件都很了解, 虽然提出的方案朴素无华, 但 : 是非常solid, 可谓程序员里的乔峰。 : 谷德宝为代表的java马工, 不可谓不是高手, 有大项目的经验, 自己做过的东西也 : 很熟, 不过感觉是过于迷失于一堆堆的流行技术, 一开口就是C*, nosql, aws, 但是 : 计算机的根基不稳,就像偷练易筋经的鸠摩智, 高手一过招就破绽太多。
|
s****u 发帖数: 1433 | |
T********i 发帖数: 2416 | 6 他这个全堆程序员,没有幕容复那个本事,甚至没有王语嫣那个见识。
顶多也就是一个裘千丈。
【在 s****u 的大作中提到】 : 赵同学又是哪个?幕容复?
|
b*******s 发帖数: 5216 | 7 他已经疯了,装不成高人了
【在 T********i 的大作中提到】 : 他这个全堆程序员,没有幕容复那个本事,甚至没有王语嫣那个见识。 : 顶多也就是一个裘千丈。
|
c****3 发帖数: 10787 | 8 就是两种思路。一种是要业界标准做法。一种是管他白猫黑猫,抓住老鼠就是好猫。第
二种也不错,比较实际。
不过发现有个缺点,火车区间车次经常变化,区间总票数也会变化。数据库和计数器不
在一起,是异步的。区间总票数变化时,后台先统计数据库剩余票数,但再去改计数器
票数的时候,因为是异步的,别人可能在这个时间差,在前台已经又把计数器的票数减
了几张,准备去改数据库。这时候会出现超卖的现象。
【在 p*******r 的大作中提到】 : 我和魏老师和谷德宝都不认识, 不过看起来这一战是魏老师大胜 : 魏老师确实水平不错, 从底层架构到硬件都很了解, 虽然提出的方案朴素无华, 但 : 是非常solid, 可谓程序员里的乔峰。 : 谷德宝为代表的java马工, 不可谓不是高手, 有大项目的经验, 自己做过的东西也 : 很熟, 不过感觉是过于迷失于一堆堆的流行技术, 一开口就是C*, nosql, aws, 但是 : 计算机的根基不稳,就像偷练易筋经的鸠摩智, 高手一过招就破绽太多。
|
T********i 发帖数: 2416 | 9 其实你再想想?
别说现在抢票用单线程,就算是多线程,也能让它想同步就同步,想异步就异步。
代价就是那么几个微秒毫秒而已。
你真以为我们做高频的萝卜快了不洗泥?这个系统的可控性也是强实时的。
【在 c****3 的大作中提到】 : 就是两种思路。一种是要业界标准做法。一种是管他白猫黑猫,抓住老鼠就是好猫。第 : 二种也不错,比较实际。 : 不过发现有个缺点,火车区间车次经常变化,区间总票数也会变化。数据库和计数器不 : 在一起,是异步的。区间总票数变化时,后台先统计数据库剩余票数,但再去改计数器 : 票数的时候,因为是异步的,别人可能在这个时间差,在前台已经又把计数器的票数减 : 了几张,准备去改数据库。这时候会出现超卖的现象。
|
c****3 发帖数: 10787 | 10 虽然是单线程,后台改计数器的时候,前台没法同时改计数器。但是统计数据库区间剩
票数的程序,好像也必须在这个线程运行,才能不出现超卖。还是有什么其他方法?
因为区间剩余总票数很容易变化,比如有人退票。数据库和计数器两者必须保持一致。
【在 T********i 的大作中提到】 : 其实你再想想? : 别说现在抢票用单线程,就算是多线程,也能让它想同步就同步,想异步就异步。 : 代价就是那么几个微秒毫秒而已。 : 你真以为我们做高频的萝卜快了不洗泥?这个系统的可控性也是强实时的。
|
|
|
T********i 发帖数: 2416 | 11 其实数据库是打酱油的。也就是备份一下,还是异步。
计数器可靠性靠串联一串单机保证。同步就是sequenced message log。
想象一个状态自动机,初始状态和所有输出决定当前状态。
snapshot后可以忘掉以前的消息。
我早就说过,其实这是messaging system。
【在 c****3 的大作中提到】 : 虽然是单线程,后台改计数器的时候,前台没法同时改计数器。但是统计数据库区间剩 : 票数的程序,好像也必须在这个线程运行,才能不出现超卖。还是有什么其他方法? : 因为区间剩余总票数很容易变化,比如有人退票。数据库和计数器两者必须保持一致。
|
T********i 发帖数: 2416 | 12 回到你的问题,改计数器要发admin消息,和抢票消息一样。
【在 T********i 的大作中提到】 : 其实数据库是打酱油的。也就是备份一下,还是异步。 : 计数器可靠性靠串联一串单机保证。同步就是sequenced message log。 : 想象一个状态自动机,初始状态和所有输出决定当前状态。 : snapshot后可以忘掉以前的消息。 : 我早就说过,其实这是messaging system。
|
L*****e 发帖数: 8347 | 13 这个可能可以cheat一下,内存数据库的变化可以在支付的时候push到后台硬盘数据库
。支付没有完成的时候万一前台断电,未sync的部分就当是支付失败,然后把后台数据
库的数据reload进内存。。。
如果有区段车次及票数变化,也是先更新后台,如果票数减少而前台没反映出来时,也
是让它支付失败,重新抢票。。。
【在 c****3 的大作中提到】 : 虽然是单线程,后台改计数器的时候,前台没法同时改计数器。但是统计数据库区间剩 : 票数的程序,好像也必须在这个线程运行,才能不出现超卖。还是有什么其他方法? : 因为区间剩余总票数很容易变化,比如有人退票。数据库和计数器两者必须保持一致。
|
T********i 发帖数: 2416 | 14 这个我反复说了3个月了。
这是一串单机的failover。eventual consistency。
抢票请求从前往后传,只有第一台head机能做决定,只有抢到才往下传。抢不到返回拒
绝立即忘记。
其他机器只管更新状态,然后同时传给下游机。最后一台下游机传给支付机,同时生成
ack往上传。直到第一台head机收到ack,transaction才完成。
如果无故障,则一切顺利。如果有故障,只要这一串还有一台活着,交换丢失的有序
message log,可能重新指定head机就好了。
只需一个8byte的unique req id。这个还能支持实时查询。
其实,实时查询,我看用C*数据库挺好的。
【在 L*****e 的大作中提到】 : 这个可能可以cheat一下,内存数据库的变化可以在支付的时候push到后台硬盘数据库 : 。支付没有完成的时候万一前台断电,未sync的部分就当是支付失败,然后把后台数据 : 库的数据reload进内存。。。 : 如果有区段车次及票数变化,也是先更新后台,如果票数减少而前台没反映出来时,也 : 是让它支付失败,重新抢票。。。
|
c****3 发帖数: 10787 | 15 就是所有对数据库里票的增减操做,必然退票,区间车次改动,都要先改计数器,然后
再操纵数据库?这样好像是可以。
【在 T********i 的大作中提到】 : 回到你的问题,改计数器要发admin消息,和抢票消息一样。
|
w**z 发帖数: 8232 | 16 和我猜的一样,老魏只要保证计数器“大致“能工作就行了,其他简单的事情,HA 啦
, Network partition啦,replication 啦,就交给屌丝Java 程序员就可以。
http://www.mitbbs.com/article/Programming/31315299_0.html
【在 L*****e 的大作中提到】 : 这个可能可以cheat一下,内存数据库的变化可以在支付的时候push到后台硬盘数据库 : 。支付没有完成的时候万一前台断电,未sync的部分就当是支付失败,然后把后台数据 : 库的数据reload进内存。。。 : 如果有区段车次及票数变化,也是先更新后台,如果票数减少而前台没反映出来时,也 : 是让它支付失败,重新抢票。。。
|
T********i 发帖数: 2416 | 17 数据库就是糊弄人的,给人看的,反正这么大并发,异步更新快点慢点有区别么?
所有改车次,改票,等等的,我们称为critical path,都要通过消息的。
消息是一切,是message queue,是transaction manager,是journal log。
【在 c****3 的大作中提到】 : 就是所有对数据库里票的增减操做,必然退票,区间车次改动,都要先改计数器,然后 : 再操纵数据库?这样好像是可以。
|
T********i 发帖数: 2416 | 18 你又错了。java程序员维护的那个数据库,是糊弄人的。给人看着玩的。
计数器才是critical path。
怎么你们这些自称java程序员的,本版我没看到一个理解力好的?
【在 w**z 的大作中提到】 : 和我猜的一样,老魏只要保证计数器“大致“能工作就行了,其他简单的事情,HA 啦 : , Network partition啦,replication 啦,就交给屌丝Java 程序员就可以。 : http://www.mitbbs.com/article/Programming/31315299_0.html
|
g*****g 发帖数: 34805 | 19 很奇怪的是这些java程序员都是在知名互联网公司工作的,都有相关经验,而且貌似都
不认同你的做法。另外,这么多大网站,为啥就没听说那个用high frequency的那套单
机强耦合,是因为大家都不如魏公公聪明吗?
现在知道民科为啥被鄙视了吧。
【在 T********i 的大作中提到】 : 你又错了。java程序员维护的那个数据库,是糊弄人的。给人看着玩的。 : 计数器才是critical path。 : 怎么你们这些自称java程序员的,本版我没看到一个理解力好的?
|
b*******s 发帖数: 5216 | 20 你在说赵策?
【在 g*****g 的大作中提到】 : 很奇怪的是这些java程序员都是在知名互联网公司工作的,都有相关经验,而且貌似都 : 不认同你的做法。另外,这么多大网站,为啥就没听说那个用high frequency的那套单 : 机强耦合,是因为大家都不如魏公公聪明吗? : 现在知道民科为啥被鄙视了吧。
|
|
|
T********i 发帖数: 2416 | 21 你那点所谓的经验说实话我看就是一个屁。
就好象当男妓赚钱你就去搞gay porn,然后声称性经验比别人丰富一样。
【在 g*****g 的大作中提到】 : 很奇怪的是这些java程序员都是在知名互联网公司工作的,都有相关经验,而且貌似都 : 不认同你的做法。另外,这么多大网站,为啥就没听说那个用high frequency的那套单 : 机强耦合,是因为大家都不如魏公公聪明吗? : 现在知道民科为啥被鄙视了吧。
|
g*****g 发帖数: 34805 | 22 你一个太监,想做男妓也没能力呀。
【在 T********i 的大作中提到】 : 你那点所谓的经验说实话我看就是一个屁。 : 就好象当男妓赚钱你就去搞gay porn,然后声称性经验比别人丰富一样。
|
g*****g 发帖数: 34805 | 23 我知道wwzz, qxc都在哪混,就算zhaoce也比魏公公靠谱多了。好歹不会有decrement再
increment是atomic这种低级错误。
【在 b*******s 的大作中提到】 : 你在说赵策?
|
b*******s 发帖数: 5216 | 24 能说明什么?
【在 g*****g 的大作中提到】 : 我知道wwzz, qxc都在哪混,就算zhaoce也比魏公公靠谱多了。好歹不会有decrement再 : increment是atomic这种低级错误。
|
g*****g 发帖数: 34805 | 25 外行说内行不懂,先想想自己配吗?1万并发的网站都没做过,开口就是500万并发,纯
粹不知天高地厚。
【在 b*******s 的大作中提到】 : 能说明什么?
|
T********i 发帖数: 2416 | 26 这一堆,那一堆,就全堆了。13个CPU core不能处理5G bps的c struct协议栈。
别说,这个5年前我就用Java实现过。
【在 b*******s 的大作中提到】 : 能说明什么?
|
L*****e 发帖数: 8347 | 27 第一,因为以前没有跟踪,今天第一次知道你提过这个一串单机的failover,本来以为
魏老一直强调的是单机搞定。
第二,板油说的断电情况,你一串单机如果在一个data center,然道不是一起都断电
?如果你把这一串单机分布到不同的location,已经无法保证单机之间同步了吧?
【在 T********i 的大作中提到】 : 这个我反复说了3个月了。 : 这是一串单机的failover。eventual consistency。 : 抢票请求从前往后传,只有第一台head机能做决定,只有抢到才往下传。抢不到返回拒 : 绝立即忘记。 : 其他机器只管更新状态,然后同时传给下游机。最后一台下游机传给支付机,同时生成 : ack往上传。直到第一台head机收到ack,transaction才完成。 : 如果无故障,则一切顺利。如果有故障,只要这一串还有一台活着,交换丢失的有序 : message log,可能重新指定head机就好了。 : 只需一个8byte的unique req id。这个还能支持实时查询。 : 其实,实时查询,我看用C*数据库挺好的。
|
w**z 发帖数: 8232 | 28 别扯了,他没做过,瞎掰呢。
【在 L*****e 的大作中提到】 : 第一,因为以前没有跟踪,今天第一次知道你提过这个一串单机的failover,本来以为 : 魏老一直强调的是单机搞定。 : 第二,板油说的断电情况,你一串单机如果在一个data center,然道不是一起都断电 : ?如果你把这一串单机分布到不同的location,已经无法保证单机之间同步了吧?
|
b*******s 发帖数: 5216 | 29 嗯,可以请你介绍下你的高并发是怎么做的,挺感兴趣的
从头到尾没看到你的细节设计,讨论完老魏的,也想看看你的
【在 g*****g 的大作中提到】 : 外行说内行不懂,先想想自己配吗?1万并发的网站都没做过,开口就是500万并发,纯 : 粹不知天高地厚。
|
z****e 发帖数: 54598 | 30 老魏用来装逼的那个java class
是我告诉呀的
我现在很后悔在这种废物上浪费时间
【在 b*******s 的大作中提到】 : 能说明什么?
|
|
|
z****e 发帖数: 54598 | 31 无数人说过了,二爷都说过了,都说烂掉了
居然还在问
你也就这点水平了
【在 b*******s 的大作中提到】 : 嗯,可以请你介绍下你的高并发是怎么做的,挺感兴趣的 : 从头到尾没看到你的细节设计,讨论完老魏的,也想看看你的
|
T********i 发帖数: 2416 | 32 我一直强调的是多单机跨DC串联。
同步靠sequenced messages。只和带宽有关,throughput和latency是不同的概念。
因为是eventual consistency,只要throughput满足即可。通信的memory buffer可以
很大。
我3个多月前的第一帖声明这个系统的性能的唯一指标是带宽。只要做带宽分析就可以
了。
【在 L*****e 的大作中提到】 : 第一,因为以前没有跟踪,今天第一次知道你提过这个一串单机的failover,本来以为 : 魏老一直强调的是单机搞定。 : 第二,板油说的断电情况,你一串单机如果在一个data center,然道不是一起都断电 : ?如果你把这一串单机分布到不同的location,已经无法保证单机之间同步了吧?
|
b*******s 发帖数: 5216 | 33 不讨论到细节,连你也是可以装一下的,不是吗?
【在 z****e 的大作中提到】 : 无数人说过了,二爷都说过了,都说烂掉了 : 居然还在问 : 你也就这点水平了
|
z****e 发帖数: 54598 | 34 细节到时候查都来得及
你有脑没脑啊,当人脑是什么?机器吗?
你就是一机器吗?
【在 b*******s 的大作中提到】 : 不讨论到细节,连你也是可以装一下的,不是吗?
|
z****e 发帖数: 54598 | 35 老魏,人家amazon干活的早就对你定位了
new grad+2 years
你服气不服气?不服过去amazon试试,看给什么价格
【在 T********i 的大作中提到】 : 你那点所谓的经验说实话我看就是一个屁。 : 就好象当男妓赚钱你就去搞gay porn,然后声称性经验比别人丰富一样。
|
g*****g 发帖数: 34805 | 36 http://www.mitbbs.com/article/Programming/31281349_0.html
你可以看看这篇,前后分开,前端只管存单子,完全无锁是高并发的核心。
我老做人不爱张扬,不会一个计数器就要发N个帖子 attention whore.
后端其实用原来的legacy系统就好,我对系统出票速度就是5k-10K, 同主题还可以看到
一些对优化降低延迟的讨论。
【在 b*******s 的大作中提到】 : 嗯,可以请你介绍下你的高并发是怎么做的,挺感兴趣的 : 从头到尾没看到你的细节设计,讨论完老魏的,也想看看你的
|
x****u 发帖数: 44466 | 37 一秒出票1万都用不了
【在 g*****g 的大作中提到】 : http://www.mitbbs.com/article/Programming/31281349_0.html : 你可以看看这篇,前后分开,前端只管存单子,完全无锁是高并发的核心。 : 我老做人不爱张扬,不会一个计数器就要发N个帖子 attention whore. : 后端其实用原来的legacy系统就好,我对系统出票速度就是5k-10K, 同主题还可以看到 : 一些对优化降低延迟的讨论。
|
n*****t 发帖数: 22014 | 38 连现有的 12306 都不如,娘哎 。。。
【在 x****u 的大作中提到】 : 一秒出票1万都用不了
|
L*****e 发帖数: 8347 | 39 多谢老魏耐心解释,不过请原谅我继续打破砂锅问到底,如果意外发生,很可能是你单
机串联间的网络先断,然后你的抢票主机再当,那么这时你抢票机内存里的数据即没有
发送到串联的failover单机上,也没法在断电后保存。。。还是说,一旦串联机当机,
你抢票主机也停止接单?(这不像是failover了,这是一损俱损吧?)
也许是我思想比较陈旧,总觉得所有数据如果不能保证最终写到硬盘上,总不能保证
data persistent and consistent。。。
【在 T********i 的大作中提到】 : 我一直强调的是多单机跨DC串联。 : 同步靠sequenced messages。只和带宽有关,throughput和latency是不同的概念。 : 因为是eventual consistency,只要throughput满足即可。通信的memory buffer可以 : 很大。 : 我3个多月前的第一帖声明这个系统的性能的唯一指标是带宽。只要做带宽分析就可以 : 了。
|
n*****t 发帖数: 22014 | 40 http://www.mitbbs.com/article_t/Programming/31315135.html
【在 L*****e 的大作中提到】 : 多谢老魏耐心解释,不过请原谅我继续打破砂锅问到底,如果意外发生,很可能是你单 : 机串联间的网络先断,然后你的抢票主机再当,那么这时你抢票机内存里的数据即没有 : 发送到串联的failover单机上,也没法在断电后保存。。。还是说,一旦串联机当机, : 你抢票主机也停止接单?(这不像是failover了,这是一损俱损吧?) : 也许是我思想比较陈旧,总觉得所有数据如果不能保证最终写到硬盘上,总不能保证 : data persistent and consistent。。。
|
|
|
c****3 发帖数: 10787 | 41 我理解这个倒是简单,机器之间有个heartbeat的交换就行了
【在 L*****e 的大作中提到】 : 多谢老魏耐心解释,不过请原谅我继续打破砂锅问到底,如果意外发生,很可能是你单 : 机串联间的网络先断,然后你的抢票主机再当,那么这时你抢票机内存里的数据即没有 : 发送到串联的failover单机上,也没法在断电后保存。。。还是说,一旦串联机当机, : 你抢票主机也停止接单?(这不像是failover了,这是一损俱损吧?) : 也许是我思想比较陈旧,总觉得所有数据如果不能保证最终写到硬盘上,总不能保证 : data persistent and consistent。。。
|
x****u 发帖数: 44466 | 42 12360一秒出一万张票?有那么多票谁还抱怨买票难。
【在 n*****t 的大作中提到】 : 连现有的 12306 都不如,娘哎 。。。
|
L*****e 发帖数: 8347 | 43 这个我看了,这个和我提的在支付时到后台硬盘数据库验证并更新本质是一样的。。。
【在 n*****t 的大作中提到】 : http://www.mitbbs.com/article_t/Programming/31315135.html
|
n*****t 发帖数: 22014 | 44 双鸡热备份,前端 CACHE 鸡收到确认消息,向备份鸡 FWD。备份鸡与主鸡之间 HB
【在 c****3 的大作中提到】 : 我理解这个倒是简单,机器之间有个heartbeat的交换就行了
|
L*****e 发帖数: 8347 | 45 通过heartbeat交换通知不是问题,我的意思是这改变了failover的本质,failover应
该是你一台机当了failover挑起大梁继续工作,这里成了串联的failover机一当,或者
串联网络一出问题,干脆整个系统都不工作了,这反而是增加了failure的概率。。。
【在 c****3 的大作中提到】 : 我理解这个倒是简单,机器之间有个heartbeat的交换就行了
|
T********i 发帖数: 2416 | 46 即使数据写在硬盘上,难道你还要花时间扒硬盘不成?
其实,failover的时候,没完成的transaction可当作没发生。
只要保持eventual consistency即可。
即使主机不死,前端web机也可能死。有机器死掉服务中断几毫秒到几秒都没问题。
关键的全局规划,unique id的种类越少越好。最好只有user id和req id。我们叫
ClOrdID。client order ID。
Amazon 是买东西,点Submit。屏幕一片白。买到没买到?用户要事后主动去查。或者
等通知。
即使我们的系统没问题,用户点完submit后宕机呢?
【在 L*****e 的大作中提到】 : 多谢老魏耐心解释,不过请原谅我继续打破砂锅问到底,如果意外发生,很可能是你单 : 机串联间的网络先断,然后你的抢票主机再当,那么这时你抢票机内存里的数据即没有 : 发送到串联的failover单机上,也没法在断电后保存。。。还是说,一旦串联机当机, : 你抢票主机也停止接单?(这不像是failover了,这是一损俱损吧?) : 也许是我思想比较陈旧,总觉得所有数据如果不能保证最终写到硬盘上,总不能保证 : data persistent and consistent。。。
|
c****3 发帖数: 10787 | 47 就和OSPF路由协议一样,平时交换heart beat,先选好master和backup,master当机了
,backup变成master。
当机那一刻master的状态是没法保持了,这是没有办法的。
【在 L*****e 的大作中提到】 : 通过heartbeat交换通知不是问题,我的意思是这改变了failover的本质,failover应 : 该是你一台机当了failover挑起大梁继续工作,这里成了串联的failover机一当,或者 : 串联网络一出问题,干脆整个系统都不工作了,这反而是增加了failure的概率。。。
|
L*****e 发帖数: 8347 | 48 支付的时候扒硬盘不是大问题,本来支付的transaction就很慢。。。
我理解你前面说的是支付的transaction是走另外一个flow,串联机备份是单独的一个
flow。如果你是说先在串联机上备份,完成后再走支付的transaction。就是说串联备
份成为支付的上游,那么failure发生后,你可以当作transaction没有发生。。。
【在 T********i 的大作中提到】 : 即使数据写在硬盘上,难道你还要花时间扒硬盘不成? : 其实,failover的时候,没完成的transaction可当作没发生。 : 只要保持eventual consistency即可。 : 即使主机不死,前端web机也可能死。有机器死掉服务中断几毫秒到几秒都没问题。 : 关键的全局规划,unique id的种类越少越好。最好只有user id和req id。我们叫 : ClOrdID。client order ID。 : Amazon 是买东西,点Submit。屏幕一片白。买到没买到?用户要事后主动去查。或者 : 等通知。 : 即使我们的系统没问题,用户点完submit后宕机呢?
|
g*****g 发帖数: 34805 | 49 12306一天出5m 票,1万每秒8分钟就放完了。订单那就多多了。
【在 x****u 的大作中提到】 : 12360一秒出一万张票?有那么多票谁还抱怨买票难。
|
s***o 发帖数: 2191 | 50 这个属于乱点鸳鸯谱。
原著中乔峰跟鸠摩智也没交过手。
【在 p*******r 的大作中提到】 : 我和魏老师和谷德宝都不认识, 不过看起来这一战是魏老师大胜 : 魏老师确实水平不错, 从底层架构到硬件都很了解, 虽然提出的方案朴素无华, 但 : 是非常solid, 可谓程序员里的乔峰。 : 谷德宝为代表的java马工, 不可谓不是高手, 有大项目的经验, 自己做过的东西也 : 很熟, 不过感觉是过于迷失于一堆堆的流行技术, 一开口就是C*, nosql, aws, 但是 : 计算机的根基不稳,就像偷练易筋经的鸠摩智, 高手一过招就破绽太多。
|
|
|
T********i 发帖数: 2416 | 51 对,一旦支付了。即使最后一台死掉都不怕。
假定支付系统能link 8 byte的req id。
其实,任何支付系统都要有能力绑定用户自定义ID的。假定系统设计者不脑残。
迄今为止,我还没见过很脑残的。
最后一台如果死掉,可能要靠支付系统sync ack。
【在 L*****e 的大作中提到】 : 支付的时候扒硬盘不是大问题,本来支付的transaction就很慢。。。 : 我理解你前面说的是支付的transaction是走另外一个flow,串联机备份是单独的一个 : flow。如果你是说先在串联机上备份,完成后再走支付的transaction。就是说串联备 : 份成为支付的上游,那么failure发生后,你可以当作transaction没有发生。。。
|
x****u 发帖数: 44466 | 52 12306有几十年的乘客数据的,稍微一分析把热点拿出来独立做,一点压力也没有。
主要问题是出在前端上,应该说是没想象到抢票软件神威,没做合适的负载平衡。
【在 g*****g 的大作中提到】 : 12306一天出5m 票,1万每秒8分钟就放完了。订单那就多多了。
|
L*****e 发帖数: 8347 | 53 老魏的方案里的“failover”其实不是failover的作用,而是内存数据备份的作用。。
。不能让他的串联机身兼二职。用串联机来做内存备份一定程度解决了数据丢失的问题
,但是另一方面增加了系统fail的概率,因为要保证数据不丢失,那么就得在备份失败
时就得系统停止交易。。。
【在 c****3 的大作中提到】 : 就和OSPF路由协议一样,平时交换heart beat,先选好master和backup,master当机了 : ,backup变成master。 : 当机那一刻master的状态是没法保持了,这是没有办法的。
|
g*****g 发帖数: 34805 | 54 人机器牛逼,所以一秒能丢5m 单。
【在 L*****e 的大作中提到】 : 老魏的方案里的“failover”其实不是failover的作用,而是内存数据备份的作用。。 : 。不能让他的串联机身兼二职。用串联机来做内存备份一定程度解决了数据丢失的问题 : ,但是另一方面增加了系统fail的概率,因为要保证数据不丢失,那么就得在备份失败 : 时就得系统停止交易。。。
|
d***a 发帖数: 13752 | 55 我也问过关于可靠性的问题,后来才意识到,他那个单机fail掉时,就让用户重新买票
,因为还没出票,这样做也行得通。
【在 L*****e 的大作中提到】 : 老魏的方案里的“failover”其实不是failover的作用,而是内存数据备份的作用。。 : 。不能让他的串联机身兼二职。用串联机来做内存备份一定程度解决了数据丢失的问题 : ,但是另一方面增加了系统fail的概率,因为要保证数据不丢失,那么就得在备份失败 : 时就得系统停止交易。。。
|
T********i 发帖数: 2416 | 56 多集群系统都有fail概率增大的问题。
问题是fail的代价。停止交易几毫秒到1-2秒,应该没大问题。
前端这时候甚至可以拒绝访问。
再说了,你搞几百台web前端,还不是隔三差五有fail的?用户看起来不是一样?
这点代价,换来consistency。
【在 L*****e 的大作中提到】 : 老魏的方案里的“failover”其实不是failover的作用,而是内存数据备份的作用。。 : 。不能让他的串联机身兼二职。用串联机来做内存备份一定程度解决了数据丢失的问题 : ,但是另一方面增加了系统fail的概率,因为要保证数据不丢失,那么就得在备份失败 : 时就得系统停止交易。。。
|
L*****e 发帖数: 8347 | 57 这个不太一样,多集群系统里的failover是一台机子出了问题,请求会被自动load
balance到别的failover机子上去,对于用户来讲,根本就察觉不到任何down time。但
是你的串联机出问题时,也就是说数据内存备份这一步失败,你是停止交易呢还是继续
交易?继续交易的话,那么数据备份这块就暂时缺失,停止交易呢,等于是你备份机出
问题导致你整个系统都停下来。。。
【在 T********i 的大作中提到】 : 多集群系统都有fail概率增大的问题。 : 问题是fail的代价。停止交易几毫秒到1-2秒,应该没大问题。 : 前端这时候甚至可以拒绝访问。 : 再说了,你搞几百台web前端,还不是隔三差五有fail的?用户看起来不是一样? : 这点代价,换来consistency。
|
T********i 发帖数: 2416 | 58 怎么可能没有down time?要heartbeat interval干啥?
我这个除了heartbeat interval,还要上下游机器短暂sync,然后自动继续交易。
sync也可能丢失上游未发的消息,没发生的transaction就当没发生好了。
【在 L*****e 的大作中提到】 : 这个不太一样,多集群系统里的failover是一台机子出了问题,请求会被自动load : balance到别的failover机子上去,对于用户来讲,根本就察觉不到任何down time。但 : 是你的串联机出问题时,也就是说数据内存备份这一步失败,你是停止交易呢还是继续 : 交易?继续交易的话,那么数据备份这块就暂时缺失,停止交易呢,等于是你备份机出 : 问题导致你整个系统都停下来。。。
|
L*****e 发帖数: 8347 | 59 我是说failover用户察觉不到down time,不是说没有down time。
你的方案中,备份机当了,你抢票主机和下游哪个机子sync?还是说你有多个备份机?
这多个备份机和你的抢票主机并联?如果是这样,那么你备份机们和下游的支付及出票
transaction怎么联?并联?
【在 T********i 的大作中提到】 : 怎么可能没有down time?要heartbeat interval干啥? : 我这个除了heartbeat interval,还要上下游机器短暂sync,然后自动继续交易。 : sync也可能丢失上游未发的消息,没发生的transaction就当没发生好了。
|
c****3 发帖数: 10787 | 60 象它这种内存计数器,数据量很少,备份频率可以很高,在毫秒级别,备份message,
可以兼做heart beat用。 主机器down了,总会丢一些状态。会出现超卖现象,但是
down机也是小概率事件,偶尔超卖,问题也不大。
【在 L*****e 的大作中提到】 : 老魏的方案里的“failover”其实不是failover的作用,而是内存数据备份的作用。。 : 。不能让他的串联机身兼二职。用串联机来做内存备份一定程度解决了数据丢失的问题 : ,但是另一方面增加了系统fail的概率,因为要保证数据不丢失,那么就得在备份失败 : 时就得系统停止交易。。。
|
|
|
g*****g 发帖数: 34805 | 61 俺那么简单一个 Cassandra轮子,就能做到单数据中心废了没 downtime, 不丢数据。
你这东西差多了。
【在 T********i 的大作中提到】 : 怎么可能没有down time?要heartbeat interval干啥? : 我这个除了heartbeat interval,还要上下游机器短暂sync,然后自动继续交易。 : sync也可能丢失上游未发的消息,没发生的transaction就当没发生好了。
|
T********i 发帖数: 2416 | 62 你连IO都不懂,懂什么down tim3?
【在 g*****g 的大作中提到】 : 俺那么简单一个 Cassandra轮子,就能做到单数据中心废了没 downtime, 不丢数据。 : 你这东西差多了。
|
T********i 发帖数: 2416 | 63 单机串联三台,打头的是主机,其余的是备份机。
抢到票,主机更新counter,把消息依次下传,其余的收到消息,更新状态,同时下传。
最后一台,更新状态,同时传给支付机,同时生成ack,ack依次上传,至主机(打头机
),主机收到ack,才会告知前端机交易完成。
现在,你设计一个协议,保证任何两台down掉,都不会丢票。
不会丢票意思是,付了款的,一定会得到通知。
同时,出票数和付款绝对会match。
但是可能有人下了单,没有任何结果,这一定是还没付款,系统崩了,系统忽略了事。
需要主动查询。
因此,钱和票绝对都管住了。至于有被piss off因为下单了没屁结果的,那谁谁说了,
屁民能咋样?
down time毫秒级。
【在 L*****e 的大作中提到】 : 我是说failover用户察觉不到down time,不是说没有down time。 : 你的方案中,备份机当了,你抢票主机和下游哪个机子sync?还是说你有多个备份机? : 这多个备份机和你的抢票主机并联?如果是这样,那么你备份机们和下游的支付及出票 : transaction怎么联?并联?
|
T********i 发帖数: 2416 | 64 你别毁我声誉。我确实eventual consistent的。
【在 c****3 的大作中提到】 : 象它这种内存计数器,数据量很少,备份频率可以很高,在毫秒级别,备份message, : 可以兼做heart beat用。 主机器down了,总会丢一些状态。会出现超卖现象,但是 : down机也是小概率事件,偶尔超卖,问题也不大。
|
c****3 发帖数: 10787 | 65 我刚看到你设计的协议,这样确实是可以保持一致的。顺序向下传消息,等待回应的线
程和更新计数器的线程是一个吗?
【在 T********i 的大作中提到】 : 你别毁我声誉。我确实eventual consistent的。
|
z*******3 发帖数: 13709 | 66 eventually consistent
不是eventual consistent
老外语法比你强一万倍
【在 T********i 的大作中提到】 : 你别毁我声誉。我确实eventual consistent的。
|
T********i 发帖数: 2416 | 67 肯定不是一个线程。
【在 c****3 的大作中提到】 : 我刚看到你设计的协议,这样确实是可以保持一致的。顺序向下传消息,等待回应的线 : 程和更新计数器的线程是一个吗?
|
d***a 发帖数: 13752 | 68 说白了,你做的系统里有一台机器专门做票的调度,告诉谁谁谁应该坐
哪个座位。另一台机器按调度的结果来收钱,出票据和记录。第二台机
器用常规数据库系统,保证不出错,数据也不掉。
做调度的机器出了问题,有的人买票请求就可能被丢掉了,但不会被收
钱。第一台机器重启后,从第二台机器里拿来记录,重建自己的记录,
搞清楚哪些座位的哪些区间是空闲的,再开始调度。这样说对吧?
【在 T********i 的大作中提到】 : 你别毁我声誉。我确实eventual consistent的。
|
T********i 发帖数: 2416 | 69 连调度都不做。只是一个计数器告诉你买到票了。
确定买到票了,再由另外机器分座位都行。
你可以想象3台单机串联,只有第一台做决定,其它的只更新状态,前后传递消息。
【在 d***a 的大作中提到】 : 说白了,你做的系统里有一台机器专门做票的调度,告诉谁谁谁应该坐 : 哪个座位。另一台机器按调度的结果来收钱,出票据和记录。第二台机 : 器用常规数据库系统,保证不出错,数据也不掉。 : 做调度的机器出了问题,有的人买票请求就可能被丢掉了,但不会被收 : 钱。第一台机器重启后,从第二台机器里拿来记录,重建自己的记录, : 搞清楚哪些座位的哪些区间是空闲的,再开始调度。这样说对吧?
|
c****3 发帖数: 10787 | 70 好像计数器更新也是靠消息驱动的。
所以你还得做一个FIFO 的Queue,更新完计数器,把消息放到Queue尾,另一个线程从
Queue头读消息,发给下一个机器。
【在 T********i 的大作中提到】 : 肯定不是一个线程。
|
|
|
T********i 发帖数: 2416 | 71 sequenced message么,我一直都这么说。sequence是关键。因为,第一,有次序,第
二,不能丢。有sequence gap要补上,也就是,fail后sync。
【在 c****3 的大作中提到】 : 好像计数器更新也是靠消息驱动的。 : 所以你还得做一个FIFO 的Queue,更新完计数器,把消息放到Queue尾,另一个线程从 : Queue头读消息,发给下一个机器。
|
L*****e 发帖数: 8347 | 72 我理解串联的意思是A-> B-> C-> D-> 下游支付出票。。。
现在B当机了,或者说A到B的网络断了,你的方案A就连到了C?这不叫串联了吧?
传。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 T********i 的大作中提到】 : 单机串联三台,打头的是主机,其余的是备份机。 : 抢到票,主机更新counter,把消息依次下传,其余的收到消息,更新状态,同时下传。 : 最后一台,更新状态,同时传给支付机,同时生成ack,ack依次上传,至主机(打头机 : ),主机收到ack,才会告知前端机交易完成。 : 现在,你设计一个协议,保证任何两台down掉,都不会丢票。 : 不会丢票意思是,付了款的,一定会得到通知。 : 同时,出票数和付款绝对会match。 : 但是可能有人下了单,没有任何结果,这一定是还没付款,系统崩了,系统忽略了事。 : 需要主动查询。 : 因此,钱和票绝对都管住了。至于有被piss off因为下单了没屁结果的,那谁谁说了,
|
T********i 发帖数: 2416 | 73 还是串联,是fail后重新拓扑。
【在 L*****e 的大作中提到】 : 我理解串联的意思是A-> B-> C-> D-> 下游支付出票。。。 : 现在B当机了,或者说A到B的网络断了,你的方案A就连到了C?这不叫串联了吧? : : 传。 : ★ 发自iPhone App: ChineseWeb 8.2.2
|
n*****t 发帖数: 22014 | 74 消息串联,物理都在一个 hub 上, 主机之间民主选举谁先上谁后上
【在 L*****e 的大作中提到】 : 我理解串联的意思是A-> B-> C-> D-> 下游支付出票。。。 : 现在B当机了,或者说A到B的网络断了,你的方案A就连到了C?这不叫串联了吧? : : 传。 : ★ 发自iPhone App: ChineseWeb 8.2.2
|
T********i 发帖数: 2416 | 75 可以跨DC
【在 n*****t 的大作中提到】 : 消息串联,物理都在一个 hub 上, 主机之间民主选举谁先上谁后上
|
s******y 发帖数: 416 | 76 闭嘴!大人说话S13别插嘴!
【在 z*******3 的大作中提到】 : eventually consistent : 不是eventual consistent : 老外语法比你强一万倍
|
n*****t 发帖数: 22014 | 77 我们蓝翔技校一直用 HUB 哈哈
【在 T********i 的大作中提到】 : 可以跨DC
|
T********i 发帖数: 2416 | 78 其实我也一直用hub。
Arista 7系列。latency 500ns。
【在 n*****t 的大作中提到】 : 我们蓝翔技校一直用 HUB 哈哈
|
d***a 发帖数: 13752 | 79 如果是这样,我感觉你这个算法会有点问题...但我也不肯定。
【在 T********i 的大作中提到】 : 连调度都不做。只是一个计数器告诉你买到票了。 : 确定买到票了,再由另外机器分座位都行。 : 你可以想象3台单机串联,只有第一台做决定,其它的只更新状态,前后传递消息。
|
L*****e 发帖数: 8347 | 80 哦,现在基本听明白了,算是把三个月前漏掉的讨论补了补,多谢!
★ 发自iPhone App: ChineseWeb 8.2.2
【在 T********i 的大作中提到】 : 还是串联,是fail后重新拓扑。
|
|
|
T********i 发帖数: 2416 | 81 其实,双向都是sequenced message。只要最后一台剩下,consistency就有保障。
我这里,最后一台是支付系统。
前面还要留一台我的计数器机才能提供服务。而且,支付系统挂了,我的计数器机里还
有journal log。
【在 d***a 的大作中提到】 : 如果是这样,我感觉你这个算法会有点问题...但我也不肯定。
|
d***a 发帖数: 13752 | 82 构思是不错,感觉还可以简化,简单的可靠度高,对吧。
【在 T********i 的大作中提到】 : 其实,双向都是sequenced message。只要最后一台剩下,consistency就有保障。 : 我这里,最后一台是支付系统。 : 前面还要留一台我的计数器机才能提供服务。而且,支付系统挂了,我的计数器机里还 : 有journal log。
|
T********i 发帖数: 2416 | 83 我的设计就是一个messaging system。
如果你能再简化,那当然好。
【在 d***a 的大作中提到】 : 构思是不错,感觉还可以简化,简单的可靠度高,对吧。
|
s*******y 发帖数: 851 | 84 好虫的方案比老魏的强,老魏的实际上根本不可行,纯粹技术忽悠型。
【在 p*******r 的大作中提到】 : 我和魏老师和谷德宝都不认识, 不过看起来这一战是魏老师大胜 : 魏老师确实水平不错, 从底层架构到硬件都很了解, 虽然提出的方案朴素无华, 但 : 是非常solid, 可谓程序员里的乔峰。 : 谷德宝为代表的java马工, 不可谓不是高手, 有大项目的经验, 自己做过的东西也 : 很熟, 不过感觉是过于迷失于一堆堆的流行技术, 一开口就是C*, nosql, aws, 但是 : 计算机的根基不稳,就像偷练易筋经的鸠摩智, 高手一过招就破绽太多。
|
b*******s 发帖数: 5216 | 85 老魏的理论上可行的,具体看谁来做
【在 s*******y 的大作中提到】 : 好虫的方案比老魏的强,老魏的实际上根本不可行,纯粹技术忽悠型。
|
z*******3 发帖数: 13709 | 86 老魏自己都不敢做
有本事你来做
【在 b*******s 的大作中提到】 : 老魏的理论上可行的,具体看谁来做
|
w**z 发帖数: 8232 | 87 他那一看就是临时想出来的,先说单机,搞不定了HA, 就说要串联。那东西那么简单?
没做过的就是纯粹瞎掰。实现起来问题多了去了。
【在 b*******s 的大作中提到】 : 老魏的理论上可行的,具体看谁来做
|
c******3 发帖数: 296 | 88 一串单机的failover比一群节点的cluster的failover好吗?一群节点的cluster也可以
选一台作head,其他机器只管更新状态。
【在 T********i 的大作中提到】 : 这个我反复说了3个月了。 : 这是一串单机的failover。eventual consistency。 : 抢票请求从前往后传,只有第一台head机能做决定,只有抢到才往下传。抢不到返回拒 : 绝立即忘记。 : 其他机器只管更新状态,然后同时传给下游机。最后一台下游机传给支付机,同时生成 : ack往上传。直到第一台head机收到ack,transaction才完成。 : 如果无故障,则一切顺利。如果有故障,只要这一串还有一台活着,交换丢失的有序 : message log,可能重新指定head机就好了。 : 只需一个8byte的unique req id。这个还能支持实时查询。 : 其实,实时查询,我看用C*数据库挺好的。
|
n*****t 发帖数: 22014 | 89 串是逻辑概念,不是物理拓扑
【在 c******3 的大作中提到】 : 一串单机的failover比一群节点的cluster的failover好吗?一群节点的cluster也可以 : 选一台作head,其他机器只管更新状态。
|
g*****g 发帖数: 34805 | 90 他那个是无数人前后帮他打了无数补丁勉强撑出来的系统。IO bound的应用在那显摆计
数器,我老实在笑得不行。
【在 w**z 的大作中提到】 : 他那一看就是临时想出来的,先说单机,搞不定了HA, 就说要串联。那东西那么简单? : 没做过的就是纯粹瞎掰。实现起来问题多了去了。
|
|
|
c****3 发帖数: 10787 | 91 那个串起来的单机其实和Token-Ring差不多,这种结构是证明能工作的,就是效率差点
,所以后来不用Token-Ring了。
【在 c******3 的大作中提到】 : 一串单机的failover比一群节点的cluster的failover好吗?一群节点的cluster也可以 : 选一台作head,其他机器只管更新状态。
|
T********i 发帖数: 2416 | 92 你这么大带宽,还要求跨DC同步,这是唯一的解决方案。
不是我小瞧C*。真要较真,3个DC跨DC failover,即使没有数据紧耦合,5M TPS/s也要
瘫。
【在 c****3 的大作中提到】 : 那个串起来的单机其实和Token-Ring差不多,这种结构是证明能工作的,就是效率差点 : ,所以后来不用Token-Ring了。
|