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了。
|
