请教：LCMS某蛋白发现Ｎ多species - 未名空间MITBBS历史存档

请教：LCMS某蛋白发现Ｎ多species# Chemistry - 化学

c*u2010-10-28 07:10

1 楼

UA从三番到NRT，然后转乘ANA到北京。
1.请问UA到达和ANA起飞都是在同一个terminal吗？
2.如果是同在一个terminal，那么是在同一层吗？
3.中间需要再次安检吗？
4.行李不用中间取出来吧？(这个貌似是不用取出来的，再次确认一下)

g*h2010-10-28 07:10

2 楼

父亲在医院急诊室中风被误诊成tia，CT照片里的血栓根本没有看出来，就简单根据临
床表现说是TIA，而不是中风，没有及时吃TPA药武治疗耽误了宝贵的前期治疗时间。
离开急诊室后父亲病情立马恶化，于是第二次进入急诊室，但四个小时内没有采取任何
措施，只是在测量讨论各种症状，那最紧急的四小时内我眼睁睁看父亲从正常人手脚都
能动，仅仅视力模糊手脚无力，到一侧完全瘫痪，失去语言能力。在这个过程中我守护
在父亲身边，但是急诊室里经常护士和医生都很慢，医生虽然过来询问过几次病情，但
大部分时间病房里没有医生和护士在。如果这四个小时医院及时给iv注射
blood thinner药物控制病情，哪怕吃点阿司匹林，也不至于恶化这么快。
最后急诊室医生决定给转院，虽然有一个communication的过程，但整个过程安排也是
非常缓慢。
父亲真正到达转院进入急诊治疗，两个多小时又耽误进去了。
不知道这些因为医院耽误而错过治疗时间导致了不可逆的大脑细胞坏死并瘫痪失语，医
院是否应该给予赔偿? 我觉得这种医疗事故纠纷，我应当为父亲进行维权。希望板上有
好心的律师能够帮忙梳理一下case，看看是否有维权诉讼医院的可能。多谢!

t*d2010-10-28 07:10

3 楼

有一项指标在美的华人铁定是第一，那就是钢琴的拥有率。去过了很多朋友家，但凡有
小孩的没有一家没有钢琴的，有一次，带儿子去一个小朋友家参加生日Party，一进门
就看见了一个硕大的三角钢琴巍然耸立在客厅里，然后就很好奇的打听了一下价钱，小
朋友的妈妈比了一个7字，“这么大的琴就七千刀，你买的太划算了”我恭维道。“七
千后面再加个零！”这位妈妈自豪的纠正了我的错误估计。其实，我是不太明白为什么
一定要买钢琴，一定要孩子学钢琴。但是，胳膊拧不过大腿，LD小时候学过小提琴，后
来因故中断，中国不幸少了一个小提琴家，而美国多了一个小会计。本着母梦子续的原
则，在LD在儿子三岁刚过不久，我刚拿到该年辛苦赚来的微薄奖金还没在口袋里唔热，
就飞到到了某一个我根本不认识的人-一个钢琴销售商手中。然后，LD就很积极地开始
寻找能培养出下一个朗朗的老师，结果一圈电话打过来，得到一致的回答“等你儿子五
岁在说吧”。于是，我们家放屋子里最贵的物件就悄无声息地在客厅的角落里攒起了灰
尘。在儿子吹熄5根蜡烛前几个星期，我们家史上最贵的灰尘收器齐终于迎来了它的春
天，就是不知道这春风能否吹绿LD嫁接到儿子身上的她的艺

t*u2010-10-28 07:10

4 楼

前几天，我父母去换护照，被该死的办事人员全剪了，签证在旧的护照里。现在情况是
签证上所有的信息都没有touch到，就是签证最下面一串数字和字母的最右边那个数字
旁边（还有一点距离）被剪了一个小角。不知道这算不算签证被damage了。会影响登机
和入境吗？现在都不知道怎么办好。真是后悔没有交待他们这个，国内工作人员的办事
能力真是。。。。
谢谢了！

f*72010-10-28 07:10

5 楼

之前是F-签证用CPT工作，9月份提交了485拿到receipt之后继续以CPT工作后来12月
份找到全职工作之后就开始用EAD卡了不过I-20还没有过期想问一下9月-12月之间到
底是以F1来报呢还是绿卡呢？
另外，来美国4年，一直都是学生身份。ld是公民，我们能联合报税么？？

s*n2010-10-28 07:10

6 楼

听说可以跨区了？

t*i2010-10-28 07:10

7 楼

看贴，想起过往。。
遇着他的时候，我就叫一闪一闪亮晶晶。附注是：想闪就闪。
刚离开那阵子，努力让周身喧闹。喝酒，微醺，只为忘记。
如今，当一个人心里连一个思念的人都没有的时候，真觉得孤单。
看什么都清冷。

p*r2010-10-28 07:10

8 楼

我和魏老师和谷德宝都不认识，不过看起来这一战是魏老师大胜
魏老师确实水平不错，从底层架构到硬件都很了解，虽然提出的方案朴素无华，但
是非常solid, 可谓程序员里的乔峰。
谷德宝为代表的java马工，不可谓不是高手，有大项目的经验，自己做过的东西也
很熟，不过感觉是过于迷失于一堆堆的流行技术，一开口就是C*, nosql, aws, 但是
计算机的根基不稳，就像偷练易筋经的鸠摩智，高手一过招就破绽太多。

l*e2010-10-28 07:10

9 楼

lcms某一蛋白，结果显示有大概二十几种species，质量在几十至几百Da以内浮动。蛋
白是在tris buffer里面的。sds page结果看不出异样，请问这种情况可能会是哪些原
因造成的？因为我的目的是想金属标记该蛋白(蛋白本身未加标记)，这么多species一出来，都不知道这
蛋白到底是标记上了还是没有标记上。
谢谢。

P*s2010-10-28 07:10

10 楼

1.2. 这个可以到机场网站上查吧
3. 要过个简单的安检
4. 不要取行李

【在 c*******u 的大作中提到】

: UA从三番到NRT，然后转乘ANA到北京。
: 1.请问UA到达和ANA起飞都是在同一个terminal吗？
: 2.如果是同在一个terminal，那么是在同一层吗？
: 3.中间需要再次安检吗？
: 4.行李不用中间取出来吧？(这个貌似是不用取出来的，再次确认一下)

m*a2010-10-28 07:10

11 楼

听起来确实非常令人遗憾
没有你父亲的具体的临床表现和病历信息很难进行判断。但是绝大多数脑卒中早期CT是
正常的（做CT的主要目的是排除脑出血），你是为什么会觉得“CT照片里的血栓根本没
有看出来”？

i*n2010-10-28 07:10

12 楼

damaged

【在 t****u 的大作中提到】

: 前几天，我父母去换护照，被该死的办事人员全剪了，签证在旧的护照里。现在情况是
: 签证上所有的信息都没有touch到，就是签证最下面一串数字和字母的最右边那个数字
: 旁边（还有一点距离）被剪了一个小角。不知道这算不算签证被damage了。会影响登机
: 和入境吗？现在都不知道怎么办好。真是后悔没有交待他们这个，国内工作人员的办事
: 能力真是。。。。
: 谢谢了！

f*n2010-10-28 07:10

13 楼

I-20还没有过期你就是F1身份。CPT应该是F1身份。你12月不读书了开始工作的时候就
应该失去F1身份了。
如果你12月31号有绿卡，整年是resident。否则，因为你大半年都是F1不到5年，应该
是nonresident，但是因为是resident的配偶可以选当作resident合报。

S*l2010-10-28 07:10

14 楼

网上跟人聊聊天就好了，自己再找点事做，玩玩学学的
然后某一天，发现mr right就突然出现了
tip：看到了么？

w*z2010-10-28 07:10

15 楼

你看懂了？就那魏老师的几十行code？显摆一下interlocked？

【在 p*******r 的大作中提到】

: 我和魏老师和谷德宝都不认识，不过看起来这一战是魏老师大胜
: 魏老师确实水平不错，从底层架构到硬件都很了解，虽然提出的方案朴素无华，但
: 是非常solid, 可谓程序员里的乔峰。
: 谷德宝为代表的java马工，不可谓不是高手，有大项目的经验，自己做过的东西也
: 很熟，不过感觉是过于迷失于一堆堆的流行技术，一开口就是C*, nosql, aws, 但是
: 计算机的根基不稳，就像偷练易筋经的鸠摩智，高手一过招就破绽太多。

b*g2010-10-28 07:10

16 楼

解释一下“质量在几十至几百Da以内浮动”
最好贴个图？一张图，很多说不清的都能看明白

一出来，都不知道这

【在 l*******e 的大作中提到】

: lcms某一蛋白，结果显示有大概二十几种species，质量在几十至几百Da以内浮动。蛋
: 白是在tris buffer里面的。sds page结果看不出异样，请问这种情况可能会是哪些原
: 因造成的？因为我的目的是想金属标记该蛋白(蛋白本身未加标记)，这么多species一出来，都不知道这
: 蛋白到底是标记上了还是没有标记上。
: 谢谢。

t*g2010-10-28 07:10

17 楼

应该是一个地方，小的可怜。
不过从北京回来，查的严格些，走路也多一点。从美国去，轻松愉快。

e*y2010-10-28 07:10

18 楼

你爸从早上出现头晕的症状到下午送院都多少个小时了？tPA 的timeframe是中风后3到
4.5小时内，看你的描述，即使一到er马上给药恐怕都来不及了。CT 只能看有否出血，
判断是否有堵塞需要用CT angiography。一旦错过tPA时限，药物干预效果非常有限，
blood thinner对stroke的作用主要是long term management，并不会改善中风病程。
你看到的医生护士似乎动作慢，其实是因为那时候大局已定，在急诊室没什么能做的了。

l*f2010-10-28 07:10

19 楼

签证已经作废了
联系使馆看看能不能给你补办一个

【在 t****u 的大作中提到】

: 前几天，我父母去换护照，被该死的办事人员全剪了，签证在旧的护照里。现在情况是
: 签证上所有的信息都没有touch到，就是签证最下面一串数字和字母的最右边那个数字
: 旁边（还有一点距离）被剪了一个小角。不知道这算不算签证被damage了。会影响登机
: 和入境吗？现在都不知道怎么办好。真是后悔没有交待他们这个，国内工作人员的办事
: 能力真是。。。。
: 谢谢了！

f*72010-10-28 07:10

20 楼

谢谢指导
我现在还没有拿到绿卡，我的i20也没有失效。可是我12月的工作是EAD卡开始做的，是
不是就要resident报税了整年？然后也必须要交ssn和medicare的钱了？ 5000 treaty
也没了？不好意思哈问题有点多！！

【在 f*******n 的大作中提到】

: I-20还没有过期你就是F1身份。CPT应该是F1身份。你12月不读书了开始工作的时候就
: 应该失去F1身份了。
: 如果你12月31号有绿卡，整年是resident。否则，因为你大半年都是F1不到5年，应该
: 是nonresident，但是因为是resident的配偶可以选当作resident合报。

s*82010-10-28 07:10

21 楼

patpat. 祝福你转角遇到爱

【在 t***i 的大作中提到】

: 看贴，想起过往。。
: 遇着他的时候，我就叫一闪一闪亮晶晶。附注是：想闪就闪。
: 刚离开那阵子，努力让周身喧闹。喝酒，微醺，只为忘记。
: 如今，当一个人心里连一个思念的人都没有的时候，真觉得孤单。
: 看什么都清冷。

g*g2010-10-28 07:10

22 楼

拉到吧，就一个decrement再increment不atomic的基础都不懂，自己承认到最后几张票
不稳定，最后不得不上来一堆人给他打补丁。

【在 p*******r 的大作中提到】

: 我和魏老师和谷德宝都不认识，不过看起来这一战是魏老师大胜
: 魏老师确实水平不错，从底层架构到硬件都很了解，虽然提出的方案朴素无华，但
: 是非常solid, 可谓程序员里的乔峰。
: 谷德宝为代表的java马工，不可谓不是高手，有大项目的经验，自己做过的东西也
: 很熟，不过感觉是过于迷失于一堆堆的流行技术，一开口就是C*, nosql, aws, 但是
: 计算机的根基不稳，就像偷练易筋经的鸠摩智，高手一过招就破绽太多。

fe2010-10-28 07:10

23 楼

没怎么看懂，你是说数据库搜索结果显示有来自二十几种物种的蛋白质？还是说你谱图
上有二十几个
峰？然后这些峰m/z相差几十到几百？如果是这样，会不会是带不同电荷数导致的？
还是发个图吧，顺便把实验条件说一下

一出来，都不知
道这

【在 l*******e 的大作中提到】

: lcms某一蛋白，结果显示有大概二十几种species，质量在几十至几百Da以内浮动。蛋
: 白是在tris buffer里面的。sds page结果看不出异样，请问这种情况可能会是哪些原
: 因造成的？因为我的目的是想金属标记该蛋白(蛋白本身未加标记)，这么多species一出来，都不知道这
: 蛋白到底是标记上了还是没有标记上。
: 谢谢。

x*o2010-10-28 07:10

24 楼

请问你曾经成功联系过使馆吗?是什么方式?
我给北京使馆发了传真,都3周了也没有消息.

【在 l*f 的大作中提到】

: 签证已经作废了
: 联系使馆看看能不能给你补办一个

l*g2010-10-28 07:10

25 楼

一旦用了485 EAD，身份转为AOS Pending，F1身份自动失效。

treaty

【在 f**********7 的大作中提到】

: 谢谢指导
: 我现在还没有拿到绿卡，我的i20也没有失效。可是我12月的工作是EAD卡开始做的，是
: 不是就要resident报税了整年？然后也必须要交ssn和medicare的钱了？ 5000 treaty
: 也没了？不好意思哈问题有点多！！

i*i2010-10-28 07:10

26 楼

嗯，就是也不知道阿庆嫂最后跟刁德一结婚没有.

【在 p*******r 的大作中提到】

: 我和魏老师和谷德宝都不认识，不过看起来这一战是魏老师大胜
: 魏老师确实水平不错，从底层架构到硬件都很了解，虽然提出的方案朴素无华，但
: 是非常solid, 可谓程序员里的乔峰。
: 谷德宝为代表的java马工，不可谓不是高手，有大项目的经验，自己做过的东西也
: 很熟，不过感觉是过于迷失于一堆堆的流行技术，一开口就是C*, nosql, aws, 但是
: 计算机的根基不稳，就像偷练易筋经的鸠摩智，高手一过招就破绽太多。

s*u2010-10-28 07:10

27 楼

赵同学又是哪个？幕容复？

T*i2010-10-28 07:10

28 楼

他这个全堆程序员，没有幕容复那个本事，甚至没有王语嫣那个见识。
顶多也就是一个裘千丈。

【在 s****u 的大作中提到】

: 赵同学又是哪个？幕容复？

b*s2010-10-28 07:10

29 楼

他已经疯了，装不成高人了

【在 T********i 的大作中提到】

: 他这个全堆程序员，没有幕容复那个本事，甚至没有王语嫣那个见识。
: 顶多也就是一个裘千丈。

c*32010-10-28 07:10

30 楼

就是两种思路。一种是要业界标准做法。一种是管他白猫黑猫，抓住老鼠就是好猫。第
二种也不错，比较实际。
不过发现有个缺点，火车区间车次经常变化，区间总票数也会变化。数据库和计数器不
在一起，是异步的。区间总票数变化时，后台先统计数据库剩余票数，但再去改计数器
票数的时候，因为是异步的，别人可能在这个时间差，在前台已经又把计数器的票数减
了几张，准备去改数据库。这时候会出现超卖的现象。

【在 p*******r 的大作中提到】

: 我和魏老师和谷德宝都不认识，不过看起来这一战是魏老师大胜
: 魏老师确实水平不错，从底层架构到硬件都很了解，虽然提出的方案朴素无华，但
: 是非常solid, 可谓程序员里的乔峰。
: 谷德宝为代表的java马工，不可谓不是高手，有大项目的经验，自己做过的东西也
: 很熟，不过感觉是过于迷失于一堆堆的流行技术，一开口就是C*, nosql, aws, 但是
: 计算机的根基不稳，就像偷练易筋经的鸠摩智，高手一过招就破绽太多。

T*i2010-10-28 07:10

31 楼

其实你再想想？
别说现在抢票用单线程，就算是多线程，也能让它想同步就同步，想异步就异步。
代价就是那么几个微秒毫秒而已。
你真以为我们做高频的萝卜快了不洗泥？这个系统的可控性也是强实时的。

【在 c****3 的大作中提到】

: 就是两种思路。一种是要业界标准做法。一种是管他白猫黑猫，抓住老鼠就是好猫。第
: 二种也不错，比较实际。
: 不过发现有个缺点，火车区间车次经常变化，区间总票数也会变化。数据库和计数器不
: 在一起，是异步的。区间总票数变化时，后台先统计数据库剩余票数，但再去改计数器
: 票数的时候，因为是异步的，别人可能在这个时间差，在前台已经又把计数器的票数减
: 了几张，准备去改数据库。这时候会出现超卖的现象。

c*32010-10-28 07:10

32 楼

虽然是单线程，后台改计数器的时候，前台没法同时改计数器。但是统计数据库区间剩
票数的程序，好像也必须在这个线程运行，才能不出现超卖。还是有什么其他方法？
因为区间剩余总票数很容易变化，比如有人退票。数据库和计数器两者必须保持一致。

【在 T********i 的大作中提到】

: 其实你再想想？
: 别说现在抢票用单线程，就算是多线程，也能让它想同步就同步，想异步就异步。
: 代价就是那么几个微秒毫秒而已。
: 你真以为我们做高频的萝卜快了不洗泥？这个系统的可控性也是强实时的。

T*i2010-10-28 07:10

33 楼

其实数据库是打酱油的。也就是备份一下，还是异步。
计数器可靠性靠串联一串单机保证。同步就是sequenced message log。
想象一个状态自动机，初始状态和所有输出决定当前状态。
snapshot后可以忘掉以前的消息。
我早就说过，其实这是messaging system。

【在 c****3 的大作中提到】

: 虽然是单线程，后台改计数器的时候，前台没法同时改计数器。但是统计数据库区间剩
: 票数的程序，好像也必须在这个线程运行，才能不出现超卖。还是有什么其他方法？
: 因为区间剩余总票数很容易变化，比如有人退票。数据库和计数器两者必须保持一致。

T*i2010-10-28 07:10

34 楼

回到你的问题，改计数器要发admin消息，和抢票消息一样。

【在 T********i 的大作中提到】

: 其实数据库是打酱油的。也就是备份一下，还是异步。
: 计数器可靠性靠串联一串单机保证。同步就是sequenced message log。
: 想象一个状态自动机，初始状态和所有输出决定当前状态。
: snapshot后可以忘掉以前的消息。
: 我早就说过，其实这是messaging system。

L*e2010-10-28 07:10

35 楼

这个可能可以cheat一下，内存数据库的变化可以在支付的时候push到后台硬盘数据库
。支付没有完成的时候万一前台断电，未sync的部分就当是支付失败，然后把后台数据
库的数据reload进内存。。。
如果有区段车次及票数变化，也是先更新后台，如果票数减少而前台没反映出来时，也
是让它支付失败，重新抢票。。。

【在 c****3 的大作中提到】

: 虽然是单线程，后台改计数器的时候，前台没法同时改计数器。但是统计数据库区间剩
: 票数的程序，好像也必须在这个线程运行，才能不出现超卖。还是有什么其他方法？
: 因为区间剩余总票数很容易变化，比如有人退票。数据库和计数器两者必须保持一致。

T*i2010-10-28 07:10

36 楼

这个我反复说了3个月了。
这是一串单机的failover。eventual consistency。
抢票请求从前往后传，只有第一台head机能做决定，只有抢到才往下传。抢不到返回拒
绝立即忘记。
其他机器只管更新状态，然后同时传给下游机。最后一台下游机传给支付机，同时生成
ack往上传。直到第一台head机收到ack，transaction才完成。
如果无故障，则一切顺利。如果有故障，只要这一串还有一台活着，交换丢失的有序
message log，可能重新指定head机就好了。
只需一个8byte的unique req id。这个还能支持实时查询。
其实，实时查询，我看用C*数据库挺好的。

【在 L*****e 的大作中提到】

: 这个可能可以cheat一下，内存数据库的变化可以在支付的时候push到后台硬盘数据库
: 。支付没有完成的时候万一前台断电，未sync的部分就当是支付失败，然后把后台数据
: 库的数据reload进内存。。。
: 如果有区段车次及票数变化，也是先更新后台，如果票数减少而前台没反映出来时，也
: 是让它支付失败，重新抢票。。。

c*32010-10-28 07:10

37 楼

就是所有对数据库里票的增减操做，必然退票，区间车次改动，都要先改计数器，然后
再操纵数据库？这样好像是可以。

【在 T********i 的大作中提到】

: 回到你的问题，改计数器要发admin消息，和抢票消息一样。

w*z2010-10-28 07:10

38 楼

和我猜的一样，老魏只要保证计数器“大致“能工作就行了，其他简单的事情，HA 啦
， Network partition啦，replication 啦，就交给屌丝Java 程序员就可以。
http://www.mitbbs.com/article/Programming/31315299_0.html

【在 L*****e 的大作中提到】

: 这个可能可以cheat一下，内存数据库的变化可以在支付的时候push到后台硬盘数据库
: 。支付没有完成的时候万一前台断电，未sync的部分就当是支付失败，然后把后台数据
: 库的数据reload进内存。。。
: 如果有区段车次及票数变化，也是先更新后台，如果票数减少而前台没反映出来时，也
: 是让它支付失败，重新抢票。。。

T*i2010-10-28 07:10

39 楼

数据库就是糊弄人的，给人看的，反正这么大并发，异步更新快点慢点有区别么？
所有改车次，改票，等等的，我们称为critical path，都要通过消息的。
消息是一切，是message queue，是transaction manager，是journal log。

【在 c****3 的大作中提到】

: 就是所有对数据库里票的增减操做，必然退票，区间车次改动，都要先改计数器，然后
: 再操纵数据库？这样好像是可以。

T*i2010-10-28 07:10

40 楼

你又错了。java程序员维护的那个数据库，是糊弄人的。给人看着玩的。
计数器才是critical path。
怎么你们这些自称java程序员的，本版我没看到一个理解力好的？

【在 w**z 的大作中提到】

: 和我猜的一样，老魏只要保证计数器“大致“能工作就行了，其他简单的事情，HA 啦
: ， Network partition啦，replication 啦，就交给屌丝Java 程序员就可以。
: http://www.mitbbs.com/article/Programming/31315299_0.html

g*g2010-10-28 07:10

41 楼

很奇怪的是这些java程序员都是在知名互联网公司工作的，都有相关经验，而且貌似都
不认同你的做法。另外，这么多大网站，为啥就没听说那个用high frequency的那套单
机强耦合，是因为大家都不如魏公公聪明吗？
现在知道民科为啥被鄙视了吧。

【在 T********i 的大作中提到】

: 你又错了。java程序员维护的那个数据库，是糊弄人的。给人看着玩的。
: 计数器才是critical path。
: 怎么你们这些自称java程序员的，本版我没看到一个理解力好的？

b*s2010-10-28 07:10

42 楼

你在说赵策？

【在 g*****g 的大作中提到】

: 很奇怪的是这些java程序员都是在知名互联网公司工作的，都有相关经验，而且貌似都
: 不认同你的做法。另外，这么多大网站，为啥就没听说那个用high frequency的那套单
: 机强耦合，是因为大家都不如魏公公聪明吗？
: 现在知道民科为啥被鄙视了吧。

T*i2010-10-28 07:10

43 楼

你那点所谓的经验说实话我看就是一个屁。
就好象当男妓赚钱你就去搞gay porn，然后声称性经验比别人丰富一样。

【在 g*****g 的大作中提到】

: 很奇怪的是这些java程序员都是在知名互联网公司工作的，都有相关经验，而且貌似都
: 不认同你的做法。另外，这么多大网站，为啥就没听说那个用high frequency的那套单
: 机强耦合，是因为大家都不如魏公公聪明吗？
: 现在知道民科为啥被鄙视了吧。

g*g2010-10-28 07:10

44 楼

你一个太监，想做男妓也没能力呀。

【在 T********i 的大作中提到】

: 你那点所谓的经验说实话我看就是一个屁。
: 就好象当男妓赚钱你就去搞gay porn，然后声称性经验比别人丰富一样。

g*g2010-10-28 07:10

45 楼

我知道wwzz, qxc都在哪混，就算zhaoce也比魏公公靠谱多了。好歹不会有decrement再
increment是atomic这种低级错误。

【在 b*******s 的大作中提到】

: 你在说赵策？

b*s2010-10-28 07:10

46 楼

能说明什么？

【在 g*****g 的大作中提到】

: 我知道wwzz, qxc都在哪混，就算zhaoce也比魏公公靠谱多了。好歹不会有decrement再
: increment是atomic这种低级错误。

g*g2010-10-28 07:10

47 楼

外行说内行不懂，先想想自己配吗？1万并发的网站都没做过，开口就是500万并发，纯
粹不知天高地厚。

【在 b*******s 的大作中提到】

: 能说明什么？

T*i2010-10-28 07:10

48 楼

这一堆，那一堆，就全堆了。13个CPU core不能处理5G bps的c struct协议栈。
别说，这个5年前我就用Java实现过。

【在 b*******s 的大作中提到】

: 能说明什么？

L*e2010-10-28 07:10

49 楼

第一，因为以前没有跟踪，今天第一次知道你提过这个一串单机的failover，本来以为
魏老一直强调的是单机搞定。
第二，板油说的断电情况，你一串单机如果在一个data center，然道不是一起都断电
？如果你把这一串单机分布到不同的location，已经无法保证单机之间同步了吧？

【在 T********i 的大作中提到】

: 这个我反复说了3个月了。
: 这是一串单机的failover。eventual consistency。
: 抢票请求从前往后传，只有第一台head机能做决定，只有抢到才往下传。抢不到返回拒
: 绝立即忘记。
: 其他机器只管更新状态，然后同时传给下游机。最后一台下游机传给支付机，同时生成
: ack往上传。直到第一台head机收到ack，transaction才完成。
: 如果无故障，则一切顺利。如果有故障，只要这一串还有一台活着，交换丢失的有序
: message log，可能重新指定head机就好了。
: 只需一个8byte的unique req id。这个还能支持实时查询。
: 其实，实时查询，我看用C*数据库挺好的。

w*z2010-10-28 07:10

50 楼

别扯了，他没做过，瞎掰呢。

【在 L*****e 的大作中提到】

: 第一，因为以前没有跟踪，今天第一次知道你提过这个一串单机的failover，本来以为
: 魏老一直强调的是单机搞定。
: 第二，板油说的断电情况，你一串单机如果在一个data center，然道不是一起都断电
: ？如果你把这一串单机分布到不同的location，已经无法保证单机之间同步了吧？

b*s2010-10-28 07:10

51 楼

嗯，可以请你介绍下你的高并发是怎么做的，挺感兴趣的
从头到尾没看到你的细节设计，讨论完老魏的，也想看看你的

【在 g*****g 的大作中提到】

: 外行说内行不懂，先想想自己配吗？1万并发的网站都没做过，开口就是500万并发，纯
: 粹不知天高地厚。

z*e2010-10-28 07:10

52 楼

老魏用来装逼的那个java class
是我告诉呀的
我现在很后悔在这种废物上浪费时间

【在 b*******s 的大作中提到】

: 能说明什么？

z*e2010-10-28 07:10

53 楼

无数人说过了，二爷都说过了，都说烂掉了
居然还在问
你也就这点水平了

【在 b*******s 的大作中提到】

: 嗯，可以请你介绍下你的高并发是怎么做的，挺感兴趣的
: 从头到尾没看到你的细节设计，讨论完老魏的，也想看看你的

T*i2010-10-28 07:10

54 楼

我一直强调的是多单机跨DC串联。
同步靠sequenced messages。只和带宽有关，throughput和latency是不同的概念。
因为是eventual consistency，只要throughput满足即可。通信的memory buffer可以
很大。
我3个多月前的第一帖声明这个系统的性能的唯一指标是带宽。只要做带宽分析就可以
了。

【在 L*****e 的大作中提到】

: 第一，因为以前没有跟踪，今天第一次知道你提过这个一串单机的failover，本来以为
: 魏老一直强调的是单机搞定。
: 第二，板油说的断电情况，你一串单机如果在一个data center，然道不是一起都断电
: ？如果你把这一串单机分布到不同的location，已经无法保证单机之间同步了吧？

b*s2010-10-28 07:10

55 楼

不讨论到细节，连你也是可以装一下的，不是吗？

【在 z****e 的大作中提到】

: 无数人说过了，二爷都说过了，都说烂掉了
: 居然还在问
: 你也就这点水平了

z*e2010-10-28 07:10

56 楼

细节到时候查都来得及
你有脑没脑啊，当人脑是什么？机器吗？
你就是一机器吗？

【在 b*******s 的大作中提到】

: 不讨论到细节，连你也是可以装一下的，不是吗？

z*e2010-10-28 07:10

57 楼

老魏，人家amazon干活的早就对你定位了
new grad+2 years
你服气不服气？不服过去amazon试试，看给什么价格

【在 T********i 的大作中提到】

: 你那点所谓的经验说实话我看就是一个屁。
: 就好象当男妓赚钱你就去搞gay porn，然后声称性经验比别人丰富一样。

g*g2010-10-28 07:10

58 楼

http://www.mitbbs.com/article/Programming/31281349_0.html
你可以看看这篇，前后分开，前端只管存单子，完全无锁是高并发的核心。
我老做人不爱张扬，不会一个计数器就要发N个帖子 attention whore.
后端其实用原来的legacy系统就好，我对系统出票速度就是5k-10K, 同主题还可以看到
一些对优化降低延迟的讨论。

【在 b*******s 的大作中提到】

: 嗯，可以请你介绍下你的高并发是怎么做的，挺感兴趣的
: 从头到尾没看到你的细节设计，讨论完老魏的，也想看看你的

x*u2010-10-28 07:10

59 楼

一秒出票1万都用不了

【在 g*****g 的大作中提到】

: http://www.mitbbs.com/article/Programming/31281349_0.html
: 你可以看看这篇，前后分开，前端只管存单子，完全无锁是高并发的核心。
: 我老做人不爱张扬，不会一个计数器就要发N个帖子 attention whore.
: 后端其实用原来的legacy系统就好，我对系统出票速度就是5k-10K, 同主题还可以看到
: 一些对优化降低延迟的讨论。

n*t2010-10-28 07:10

60 楼

连现有的 12306 都不如，娘哎。。。

【在 x****u 的大作中提到】

: 一秒出票1万都用不了

L*e2010-10-28 07:10

61 楼

多谢老魏耐心解释，不过请原谅我继续打破砂锅问到底，如果意外发生，很可能是你单
机串联间的网络先断，然后你的抢票主机再当，那么这时你抢票机内存里的数据即没有
发送到串联的failover单机上，也没法在断电后保存。。。还是说，一旦串联机当机，
你抢票主机也停止接单？（这不像是failover了，这是一损俱损吧？）
也许是我思想比较陈旧，总觉得所有数据如果不能保证最终写到硬盘上，总不能保证
data persistent and consistent。。。

【在 T********i 的大作中提到】

: 我一直强调的是多单机跨DC串联。
: 同步靠sequenced messages。只和带宽有关，throughput和latency是不同的概念。
: 因为是eventual consistency，只要throughput满足即可。通信的memory buffer可以
: 很大。
: 我3个多月前的第一帖声明这个系统的性能的唯一指标是带宽。只要做带宽分析就可以
: 了。

n*t2010-10-28 07:10

62 楼

http://www.mitbbs.com/article_t/Programming/31315135.html

【在 L*****e 的大作中提到】

: 多谢老魏耐心解释，不过请原谅我继续打破砂锅问到底，如果意外发生，很可能是你单
: 机串联间的网络先断，然后你的抢票主机再当，那么这时你抢票机内存里的数据即没有
: 发送到串联的failover单机上，也没法在断电后保存。。。还是说，一旦串联机当机，
: 你抢票主机也停止接单？（这不像是failover了，这是一损俱损吧？）
: 也许是我思想比较陈旧，总觉得所有数据如果不能保证最终写到硬盘上，总不能保证
: data persistent and consistent。。。

c*32010-10-28 07:10

63 楼

我理解这个倒是简单，机器之间有个heartbeat的交换就行了

【在 L*****e 的大作中提到】

: 多谢老魏耐心解释，不过请原谅我继续打破砂锅问到底，如果意外发生，很可能是你单
: 机串联间的网络先断，然后你的抢票主机再当，那么这时你抢票机内存里的数据即没有
: 发送到串联的failover单机上，也没法在断电后保存。。。还是说，一旦串联机当机，
: 你抢票主机也停止接单？（这不像是failover了，这是一损俱损吧？）
: 也许是我思想比较陈旧，总觉得所有数据如果不能保证最终写到硬盘上，总不能保证
: data persistent and consistent。。。

x*u2010-10-28 07:10

64 楼

12360一秒出一万张票？有那么多票谁还抱怨买票难。

【在 n*****t 的大作中提到】

: 连现有的 12306 都不如，娘哎。。。

L*e2010-10-28 07:10

65 楼

这个我看了，这个和我提的在支付时到后台硬盘数据库验证并更新本质是一样的。。。

【在 n*****t 的大作中提到】

: http://www.mitbbs.com/article_t/Programming/31315135.html

n*t2010-10-28 07:10

66 楼

双鸡热备份，前端 CACHE 鸡收到确认消息，向备份鸡 FWD。备份鸡与主鸡之间 HB

【在 c****3 的大作中提到】

: 我理解这个倒是简单，机器之间有个heartbeat的交换就行了

L*e2010-10-28 07:10

67 楼

通过heartbeat交换通知不是问题，我的意思是这改变了failover的本质，failover应
该是你一台机当了failover挑起大梁继续工作，这里成了串联的failover机一当，或者
串联网络一出问题，干脆整个系统都不工作了，这反而是增加了failure的概率。。。

【在 c****3 的大作中提到】

: 我理解这个倒是简单，机器之间有个heartbeat的交换就行了

T*i2010-10-28 07:10

68 楼

即使数据写在硬盘上，难道你还要花时间扒硬盘不成？
其实，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*32010-10-28 07:10

69 楼

就和OSPF路由协议一样，平时交换heart beat，先选好master和backup，master当机了
，backup变成master。
当机那一刻master的状态是没法保持了，这是没有办法的。

【在 L*****e 的大作中提到】

: 通过heartbeat交换通知不是问题，我的意思是这改变了failover的本质，failover应
: 该是你一台机当了failover挑起大梁继续工作，这里成了串联的failover机一当，或者
: 串联网络一出问题，干脆整个系统都不工作了，这反而是增加了failure的概率。。。

L*e2010-10-28 07:10

70 楼

支付的时候扒硬盘不是大问题，本来支付的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*g2010-10-28 07:10

71 楼

12306一天出5m 票，1万每秒8分钟就放完了。订单那就多多了。

【在 x****u 的大作中提到】

: 12360一秒出一万张票？有那么多票谁还抱怨买票难。

s*o2010-10-28 07:10

72 楼

这个属于乱点鸳鸯谱。
原著中乔峰跟鸠摩智也没交过手。

【在 p*******r 的大作中提到】

: 我和魏老师和谷德宝都不认识，不过看起来这一战是魏老师大胜
: 魏老师确实水平不错，从底层架构到硬件都很了解，虽然提出的方案朴素无华，但
: 是非常solid, 可谓程序员里的乔峰。
: 谷德宝为代表的java马工，不可谓不是高手，有大项目的经验，自己做过的东西也
: 很熟，不过感觉是过于迷失于一堆堆的流行技术，一开口就是C*, nosql, aws, 但是
: 计算机的根基不稳，就像偷练易筋经的鸠摩智，高手一过招就破绽太多。

T*i2010-10-28 07:10

73 楼

对，一旦支付了。即使最后一台死掉都不怕。
假定支付系统能link 8 byte的req id。
其实，任何支付系统都要有能力绑定用户自定义ID的。假定系统设计者不脑残。
迄今为止，我还没见过很脑残的。
最后一台如果死掉，可能要靠支付系统sync ack。

【在 L*****e 的大作中提到】

: 支付的时候扒硬盘不是大问题，本来支付的transaction就很慢。。。
: 我理解你前面说的是支付的transaction是走另外一个flow，串联机备份是单独的一个
: flow。如果你是说先在串联机上备份，完成后再走支付的transaction。就是说串联备
: 份成为支付的上游，那么failure发生后，你可以当作transaction没有发生。。。

x*u2010-10-28 07:10

74 楼

12306有几十年的乘客数据的，稍微一分析把热点拿出来独立做，一点压力也没有。
主要问题是出在前端上，应该说是没想象到抢票软件神威，没做合适的负载平衡。

【在 g*****g 的大作中提到】

: 12306一天出5m 票，1万每秒8分钟就放完了。订单那就多多了。

L*e2010-10-28 07:10

75 楼

老魏的方案里的“failover”其实不是failover的作用，而是内存数据备份的作用。。
。不能让他的串联机身兼二职。用串联机来做内存备份一定程度解决了数据丢失的问题
，但是另一方面增加了系统fail的概率，因为要保证数据不丢失，那么就得在备份失败
时就得系统停止交易。。。

【在 c****3 的大作中提到】

: 就和OSPF路由协议一样，平时交换heart beat，先选好master和backup，master当机了
: ，backup变成master。
: 当机那一刻master的状态是没法保持了，这是没有办法的。

g*g2010-10-28 07:10

76 楼

人机器牛逼，所以一秒能丢5m 单。

【在 L*****e 的大作中提到】

: 老魏的方案里的“failover”其实不是failover的作用，而是内存数据备份的作用。。
: 。不能让他的串联机身兼二职。用串联机来做内存备份一定程度解决了数据丢失的问题
: ，但是另一方面增加了系统fail的概率，因为要保证数据不丢失，那么就得在备份失败
: 时就得系统停止交易。。。

d*a2010-10-28 07:10

77 楼

我也问过关于可靠性的问题，后来才意识到，他那个单机fail掉时，就让用户重新买票
，因为还没出票，这样做也行得通。

【在 L*****e 的大作中提到】

: 老魏的方案里的“failover”其实不是failover的作用，而是内存数据备份的作用。。
: 。不能让他的串联机身兼二职。用串联机来做内存备份一定程度解决了数据丢失的问题
: ，但是另一方面增加了系统fail的概率，因为要保证数据不丢失，那么就得在备份失败
: 时就得系统停止交易。。。

T*i2010-10-28 07:10

78 楼

多集群系统都有fail概率增大的问题。
问题是fail的代价。停止交易几毫秒到1-2秒，应该没大问题。
前端这时候甚至可以拒绝访问。
再说了，你搞几百台web前端，还不是隔三差五有fail的？用户看起来不是一样？
这点代价，换来consistency。

【在 L*****e 的大作中提到】

: 老魏的方案里的“failover”其实不是failover的作用，而是内存数据备份的作用。。
: 。不能让他的串联机身兼二职。用串联机来做内存备份一定程度解决了数据丢失的问题
: ，但是另一方面增加了系统fail的概率，因为要保证数据不丢失，那么就得在备份失败
: 时就得系统停止交易。。。

L*e2010-10-28 07:10

79 楼

这个不太一样，多集群系统里的failover是一台机子出了问题，请求会被自动load
balance到别的failover机子上去，对于用户来讲，根本就察觉不到任何down time。但
是你的串联机出问题时，也就是说数据内存备份这一步失败，你是停止交易呢还是继续
交易？继续交易的话，那么数据备份这块就暂时缺失，停止交易呢，等于是你备份机出
问题导致你整个系统都停下来。。。

【在 T********i 的大作中提到】

: 多集群系统都有fail概率增大的问题。
: 问题是fail的代价。停止交易几毫秒到1-2秒，应该没大问题。
: 前端这时候甚至可以拒绝访问。
: 再说了，你搞几百台web前端，还不是隔三差五有fail的？用户看起来不是一样？
: 这点代价，换来consistency。

T*i2010-10-28 07:10

80 楼

怎么可能没有down time？要heartbeat interval干啥？
我这个除了heartbeat interval，还要上下游机器短暂sync，然后自动继续交易。
sync也可能丢失上游未发的消息，没发生的transaction就当没发生好了。

【在 L*****e 的大作中提到】

: 这个不太一样，多集群系统里的failover是一台机子出了问题，请求会被自动load
: balance到别的failover机子上去，对于用户来讲，根本就察觉不到任何down time。但
: 是你的串联机出问题时，也就是说数据内存备份这一步失败，你是停止交易呢还是继续
: 交易？继续交易的话，那么数据备份这块就暂时缺失，停止交易呢，等于是你备份机出
: 问题导致你整个系统都停下来。。。

L*e2010-10-28 07:10

81 楼

我是说failover用户察觉不到down time，不是说没有down time。
你的方案中，备份机当了，你抢票主机和下游哪个机子sync？还是说你有多个备份机？
这多个备份机和你的抢票主机并联？如果是这样，那么你备份机们和下游的支付及出票
transaction怎么联？并联？

【在 T********i 的大作中提到】

: 怎么可能没有down time？要heartbeat interval干啥？
: 我这个除了heartbeat interval，还要上下游机器短暂sync，然后自动继续交易。
: sync也可能丢失上游未发的消息，没发生的transaction就当没发生好了。

c*32010-10-28 07:10

82 楼

象它这种内存计数器，数据量很少，备份频率可以很高，在毫秒级别，备份message，
可以兼做heart beat用。主机器down了，总会丢一些状态。会出现超卖现象，但是
down机也是小概率事件，偶尔超卖，问题也不大。

【在 L*****e 的大作中提到】

: 老魏的方案里的“failover”其实不是failover的作用，而是内存数据备份的作用。。
: 。不能让他的串联机身兼二职。用串联机来做内存备份一定程度解决了数据丢失的问题
: ，但是另一方面增加了系统fail的概率，因为要保证数据不丢失，那么就得在备份失败
: 时就得系统停止交易。。。

g*g2010-10-28 07:10

83 楼

俺那么简单一个 Cassandra轮子，就能做到单数据中心废了没 downtime, 不丢数据。
你这东西差多了。

【在 T********i 的大作中提到】

: 怎么可能没有down time？要heartbeat interval干啥？
: 我这个除了heartbeat interval，还要上下游机器短暂sync，然后自动继续交易。
: sync也可能丢失上游未发的消息，没发生的transaction就当没发生好了。

T*i2010-10-28 07:10

84 楼

你连IO都不懂，懂什么down tim3？

【在 g*****g 的大作中提到】

: 俺那么简单一个 Cassandra轮子，就能做到单数据中心废了没 downtime, 不丢数据。
: 你这东西差多了。

T*i2010-10-28 07:10

85 楼

单机串联三台，打头的是主机，其余的是备份机。
抢到票，主机更新counter，把消息依次下传，其余的收到消息，更新状态，同时下传。
最后一台，更新状态，同时传给支付机，同时生成ack，ack依次上传，至主机（打头机
），主机收到ack，才会告知前端机交易完成。
现在，你设计一个协议，保证任何两台down掉，都不会丢票。
不会丢票意思是，付了款的，一定会得到通知。
同时，出票数和付款绝对会match。
但是可能有人下了单，没有任何结果，这一定是还没付款，系统崩了，系统忽略了事。
需要主动查询。
因此，钱和票绝对都管住了。至于有被piss off因为下单了没屁结果的，那谁谁说了，
屁民能咋样？
down time毫秒级。

【在 L*****e 的大作中提到】

: 我是说failover用户察觉不到down time，不是说没有down time。
: 你的方案中，备份机当了，你抢票主机和下游哪个机子sync？还是说你有多个备份机？
: 这多个备份机和你的抢票主机并联？如果是这样，那么你备份机们和下游的支付及出票
: transaction怎么联？并联？

T*i2010-10-28 07:10

86 楼

你别毁我声誉。我确实eventual consistent的。

【在 c****3 的大作中提到】

: 象它这种内存计数器，数据量很少，备份频率可以很高，在毫秒级别，备份message，
: 可以兼做heart beat用。主机器down了，总会丢一些状态。会出现超卖现象，但是
: down机也是小概率事件，偶尔超卖，问题也不大。

c*32010-10-28 07:10

87 楼

我刚看到你设计的协议，这样确实是可以保持一致的。顺序向下传消息，等待回应的线
程和更新计数器的线程是一个吗？

【在 T********i 的大作中提到】

: 你别毁我声誉。我确实eventual consistent的。

z*32010-10-28 07:10

88 楼

eventually consistent
不是eventual consistent
老外语法比你强一万倍

【在 T********i 的大作中提到】

: 你别毁我声誉。我确实eventual consistent的。

T*i2010-10-28 07:10

89 楼

肯定不是一个线程。

【在 c****3 的大作中提到】

: 我刚看到你设计的协议，这样确实是可以保持一致的。顺序向下传消息，等待回应的线
: 程和更新计数器的线程是一个吗？

d*a2010-10-28 07:10

90 楼

说白了，你做的系统里有一台机器专门做票的调度，告诉谁谁谁应该坐
哪个座位。另一台机器按调度的结果来收钱，出票据和记录。第二台机
器用常规数据库系统，保证不出错，数据也不掉。
做调度的机器出了问题，有的人买票请求就可能被丢掉了，但不会被收
钱。第一台机器重启后，从第二台机器里拿来记录，重建自己的记录，
搞清楚哪些座位的哪些区间是空闲的，再开始调度。这样说对吧？

【在 T********i 的大作中提到】

: 你别毁我声誉。我确实eventual consistent的。

T*i2010-10-28 07:10

91 楼

连调度都不做。只是一个计数器告诉你买到票了。
确定买到票了，再由另外机器分座位都行。
你可以想象3台单机串联，只有第一台做决定，其它的只更新状态，前后传递消息。

【在 d***a 的大作中提到】

: 说白了，你做的系统里有一台机器专门做票的调度，告诉谁谁谁应该坐
: 哪个座位。另一台机器按调度的结果来收钱，出票据和记录。第二台机
: 器用常规数据库系统，保证不出错，数据也不掉。
: 做调度的机器出了问题，有的人买票请求就可能被丢掉了，但不会被收
: 钱。第一台机器重启后，从第二台机器里拿来记录，重建自己的记录，
: 搞清楚哪些座位的哪些区间是空闲的，再开始调度。这样说对吧？

c*32010-10-28 07:10

92 楼

好像计数器更新也是靠消息驱动的。
所以你还得做一个FIFO 的Queue，更新完计数器，把消息放到Queue尾，另一个线程从
Queue头读消息，发给下一个机器。

【在 T********i 的大作中提到】

: 肯定不是一个线程。

T*i2010-10-28 07:10

93 楼

sequenced message么，我一直都这么说。sequence是关键。因为，第一，有次序，第
二，不能丢。有sequence gap要补上，也就是，fail后sync。

【在 c****3 的大作中提到】

: 好像计数器更新也是靠消息驱动的。
: 所以你还得做一个FIFO 的Queue，更新完计数器，把消息放到Queue尾，另一个线程从
: Queue头读消息，发给下一个机器。

L*e2010-10-28 07:10

94 楼

我理解串联的意思是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*i2010-10-28 07:10

95 楼

还是串联，是fail后重新拓扑。

【在 L*****e 的大作中提到】

: 我理解串联的意思是A-> B-> C-> D-> 下游支付出票。。。
: 现在B当机了，或者说A到B的网络断了，你的方案A就连到了C？这不叫串联了吧？
:
: 传。
: ★ 发自iPhone App: ChineseWeb 8.2.2

n*t2010-10-28 07:10

96 楼

消息串联，物理都在一个 hub 上，主机之间民主选举谁先上谁后上

【在 L*****e 的大作中提到】

: 我理解串联的意思是A-> B-> C-> D-> 下游支付出票。。。
: 现在B当机了，或者说A到B的网络断了，你的方案A就连到了C？这不叫串联了吧？
:
: 传。
: ★ 发自iPhone App: ChineseWeb 8.2.2

T*i2010-10-28 07:10

97 楼

可以跨DC

【在 n*****t 的大作中提到】

: 消息串联，物理都在一个 hub 上，主机之间民主选举谁先上谁后上

s*y2010-10-28 07:10

98 楼

闭嘴！大人说话S13别插嘴！

【在 z*******3 的大作中提到】

: eventually consistent
: 不是eventual consistent
: 老外语法比你强一万倍

n*t2010-10-28 07:10

99 楼

我们蓝翔技校一直用 HUB 哈哈

【在 T********i 的大作中提到】

: 可以跨DC

T*i2010-10-28 07:10

100 楼

其实我也一直用hub。
Arista 7系列。latency 500ns。

【在 n*****t 的大作中提到】

: 我们蓝翔技校一直用 HUB 哈哈

d*a2010-10-28 07:10

101 楼

如果是这样，我感觉你这个算法会有点问题...但我也不肯定。

【在 T********i 的大作中提到】

: 连调度都不做。只是一个计数器告诉你买到票了。
: 确定买到票了，再由另外机器分座位都行。
: 你可以想象3台单机串联，只有第一台做决定，其它的只更新状态，前后传递消息。

L*e2010-10-28 07:10

102 楼

哦，现在基本听明白了，算是把三个月前漏掉的讨论补了补，多谢！

★ 发自iPhone App: ChineseWeb 8.2.2

【在 T********i 的大作中提到】

: 还是串联，是fail后重新拓扑。

T*i2010-10-28 07:10

103 楼

其实，双向都是sequenced message。只要最后一台剩下，consistency就有保障。
我这里，最后一台是支付系统。
前面还要留一台我的计数器机才能提供服务。而且，支付系统挂了，我的计数器机里还
有journal log。

【在 d***a 的大作中提到】

: 如果是这样，我感觉你这个算法会有点问题...但我也不肯定。

d*a2010-10-28 07:10

104 楼

构思是不错，感觉还可以简化，简单的可靠度高，对吧。

【在 T********i 的大作中提到】

: 其实，双向都是sequenced message。只要最后一台剩下，consistency就有保障。
: 我这里，最后一台是支付系统。
: 前面还要留一台我的计数器机才能提供服务。而且，支付系统挂了，我的计数器机里还
: 有journal log。

T*i2010-10-28 07:10

105 楼

我的设计就是一个messaging system。
如果你能再简化，那当然好。

【在 d***a 的大作中提到】

: 构思是不错，感觉还可以简化，简单的可靠度高，对吧。

s*y2010-10-28 07:10

106 楼

好虫的方案比老魏的强，老魏的实际上根本不可行，纯粹技术忽悠型。

【在 p*******r 的大作中提到】

: 我和魏老师和谷德宝都不认识，不过看起来这一战是魏老师大胜
: 魏老师确实水平不错，从底层架构到硬件都很了解，虽然提出的方案朴素无华，但
: 是非常solid, 可谓程序员里的乔峰。
: 谷德宝为代表的java马工，不可谓不是高手，有大项目的经验，自己做过的东西也
: 很熟，不过感觉是过于迷失于一堆堆的流行技术，一开口就是C*, nosql, aws, 但是
: 计算机的根基不稳，就像偷练易筋经的鸠摩智，高手一过招就破绽太多。

b*s2010-10-28 07:10

107 楼

老魏的理论上可行的，具体看谁来做

【在 s*******y 的大作中提到】

: 好虫的方案比老魏的强，老魏的实际上根本不可行，纯粹技术忽悠型。

z*32010-10-28 07:10

108 楼

老魏自己都不敢做
有本事你来做

【在 b*******s 的大作中提到】

: 老魏的理论上可行的，具体看谁来做

w*z2010-10-28 07:10

109 楼

他那一看就是临时想出来的，先说单机，搞不定了HA, 就说要串联。那东西那么简单？
没做过的就是纯粹瞎掰。实现起来问题多了去了。

【在 b*******s 的大作中提到】

: 老魏的理论上可行的，具体看谁来做

c*32010-10-28 07:10

110 楼

一串单机的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*t2010-10-28 07:10

111 楼

串是逻辑概念，不是物理拓扑

【在 c******3 的大作中提到】

: 一串单机的failover比一群节点的cluster的failover好吗？一群节点的cluster也可以
: 选一台作head，其他机器只管更新状态。

g*g2010-10-28 07:10

112 楼

他那个是无数人前后帮他打了无数补丁勉强撑出来的系统。IO bound的应用在那显摆计
数器，我老实在笑得不行。

【在 w**z 的大作中提到】

: 他那一看就是临时想出来的，先说单机，搞不定了HA, 就说要串联。那东西那么简单？
: 没做过的就是纯粹瞎掰。实现起来问题多了去了。

c*32010-10-28 07:10

113 楼

那个串起来的单机其实和Token-Ring差不多，这种结构是证明能工作的，就是效率差点
，所以后来不用Token-Ring了。

【在 c******3 的大作中提到】

: 一串单机的failover比一群节点的cluster的failover好吗？一群节点的cluster也可以
: 选一台作head，其他机器只管更新状态。

T*i2010-10-28 07:10

114 楼

你这么大带宽，还要求跨DC同步，这是唯一的解决方案。
不是我小瞧C*。真要较真，3个DC跨DC failover，即使没有数据紧耦合，5M TPS/s也要
瘫。

【在 c****3 的大作中提到】

: 那个串起来的单机其实和Token-Ring差不多，这种结构是证明能工作的，就是效率差点
: ，所以后来不用Token-Ring了。