z****e
发帖数: 54598 | 1 细节到时候查都来得及
你有脑没脑啊，当人脑是什么？机器吗？
你就是一机器吗？ |
|
z****e
发帖数: 54598 | 2 老魏，人家amazon干活的早就对你定位了
new grad+2 years
你服气不服气？不服过去amazon试试，看给什么价格 |
|
|
|
|
L*****e
发帖数: 8347 | 6 多谢老魏耐心解释，不过请原谅我继续打破砂锅问到底，如果意外发生，很可能是你单
机串联间的网络先断，然后你的抢票主机再当，那么这时你抢票机内存里的数据即没有
发送到串联的failover单机上，也没法在断电后保存。。。还是说，一旦串联机当机，
你抢票主机也停止接单？（这不像是failover了，这是一损俱损吧？）
也许是我思想比较陈旧，总觉得所有数据如果不能保证最终写到硬盘上，总不能保证
data persistent and consistent。。。 |
|
|
c****3
发帖数: 10787 | 8 我理解这个倒是简单，机器之间有个heartbeat的交换就行了 |
|
x****u
发帖数: 44466 | 9 12360一秒出一万张票？有那么多票谁还抱怨买票难。 |
|
L*****e
发帖数: 8347 | 10 这个我看了，这个和我提的在支付时到后台硬盘数据库验证并更新本质是一样的。。。 |
|
n*****t
发帖数: 22014 | 11 双鸡热备份，前端 CACHE 鸡收到确认消息，向备份鸡 FWD。备份鸡与主鸡之间 HB |
|
L*****e
发帖数: 8347 | 12 通过heartbeat交换通知不是问题，我的意思是这改变了failover的本质，failover应
该是你一台机当了failover挑起大梁继续工作，这里成了串联的failover机一当，或者
串联网络一出问题，干脆整个系统都不工作了，这反而是增加了failure的概率。。。 |
|
T********i
发帖数: 2416 | 13 即使数据写在硬盘上，难道你还要花时间扒硬盘不成？
其实，failover的时候，没完成的transaction可当作没发生。
只要保持eventual consistency即可。
即使主机不死，前端web机也可能死。有机器死掉服务中断几毫秒到几秒都没问题。
关键的全局规划，unique id的种类越少越好。最好只有user id和req id。我们叫
ClOrdID。client order ID。
Amazon 是买东西，点Submit。屏幕一片白。买到没买到？用户要事后主动去查。或者
等通知。
即使我们的系统没问题，用户点完submit后宕机呢？ |
|
c****3
发帖数: 10787 | 14 就和OSPF路由协议一样，平时交换heart beat，先选好master和backup，master当机了
，backup变成master。
当机那一刻master的状态是没法保持了，这是没有办法的。 |
|
L*****e
发帖数: 8347 | 15 支付的时候扒硬盘不是大问题，本来支付的transaction就很慢。。。
我理解你前面说的是支付的transaction是走另外一个flow，串联机备份是单独的一个
flow。如果你是说先在串联机上备份，完成后再走支付的transaction。就是说串联备
份成为支付的上游，那么failure发生后，你可以当作transaction没有发生。。。 |
|
g*****g
发帖数: 34805 | 16 12306一天出5m 票，1万每秒8分钟就放完了。订单那就多多了。 |
|
T********i
发帖数: 2416 | 17 对，一旦支付了。即使最后一台死掉都不怕。
假定支付系统能link 8 byte的req id。
其实，任何支付系统都要有能力绑定用户自定义ID的。假定系统设计者不脑残。
迄今为止，我还没见过很脑残的。
最后一台如果死掉，可能要靠支付系统sync ack。 |
|
x****u
发帖数: 44466 | 18 12306有几十年的乘客数据的，稍微一分析把热点拿出来独立做，一点压力也没有。
主要问题是出在前端上，应该说是没想象到抢票软件神威，没做合适的负载平衡。 |
|
L*****e
发帖数: 8347 | 19 老魏的方案里的“failover”其实不是failover的作用，而是内存数据备份的作用。。
。不能让他的串联机身兼二职。用串联机来做内存备份一定程度解决了数据丢失的问题
，但是另一方面增加了系统fail的概率，因为要保证数据不丢失，那么就得在备份失败
时就得系统停止交易。。。 |
|
|
d***a
发帖数: 13752 | 21 我也问过关于可靠性的问题，后来才意识到，他那个单机fail掉时，就让用户重新买票
，因为还没出票，这样做也行得通。 |
|
T********i
发帖数: 2416 | 22 多集群系统都有fail概率增大的问题。
问题是fail的代价。停止交易几毫秒到1-2秒，应该没大问题。
前端这时候甚至可以拒绝访问。
再说了，你搞几百台web前端，还不是隔三差五有fail的？用户看起来不是一样？
这点代价，换来consistency。 |
|
L*****e
发帖数: 8347 | 23 这个不太一样，多集群系统里的failover是一台机子出了问题，请求会被自动load
balance到别的failover机子上去，对于用户来讲，根本就察觉不到任何down time。但
是你的串联机出问题时，也就是说数据内存备份这一步失败，你是停止交易呢还是继续
交易？继续交易的话，那么数据备份这块就暂时缺失，停止交易呢，等于是你备份机出
问题导致你整个系统都停下来。。。 |
|
T********i
发帖数: 2416 | 24 怎么可能没有down time？要heartbeat interval干啥？
我这个除了heartbeat interval，还要上下游机器短暂sync，然后自动继续交易。
sync也可能丢失上游未发的消息，没发生的transaction就当没发生好了。 |
|
L*****e
发帖数: 8347 | 25 我是说failover用户察觉不到down time，不是说没有down time。
你的方案中，备份机当了，你抢票主机和下游哪个机子sync？还是说你有多个备份机？
这多个备份机和你的抢票主机并联？如果是这样，那么你备份机们和下游的支付及出票
transaction怎么联？并联？ |
|
c****3
发帖数: 10787 | 26 象它这种内存计数器，数据量很少，备份频率可以很高，在毫秒级别，备份message，
可以兼做heart beat用。 主机器down了，总会丢一些状态。会出现超卖现象，但是
down机也是小概率事件，偶尔超卖，问题也不大。 |
|
g*****g
发帖数: 34805 | 27 俺那么简单一个 Cassandra轮子，就能做到单数据中心废了没 downtime, 不丢数据。
你这东西差多了。 |
|
|
T********i
发帖数: 2416 | 29 单机串联三台，打头的是主机，其余的是备份机。
抢到票，主机更新counter，把消息依次下传，其余的收到消息，更新状态，同时下传。
最后一台，更新状态，同时传给支付机，同时生成ack，ack依次上传，至主机（打头机
），主机收到ack，才会告知前端机交易完成。
现在，你设计一个协议，保证任何两台down掉，都不会丢票。
不会丢票意思是，付了款的，一定会得到通知。
同时，出票数和付款绝对会match。
但是可能有人下了单，没有任何结果，这一定是还没付款，系统崩了，系统忽略了事。
需要主动查询。
因此，钱和票绝对都管住了。至于有被piss off因为下单了没屁结果的，那谁谁说了，
屁民能咋样？
down time毫秒级。 |
|
T********i
发帖数: 2416 | 30 你别毁我声誉。我确实eventual consistent的。 |
|
c****3
发帖数: 10787 | 31 我刚看到你设计的协议，这样确实是可以保持一致的。顺序向下传消息，等待回应的线
程和更新计数器的线程是一个吗？ |
|
z*******3
发帖数: 13709 | 32 eventually consistent
不是eventual consistent
老外语法比你强一万倍 |
|
|
d***a
发帖数: 13752 | 34 说白了，你做的系统里有一台机器专门做票的调度，告诉谁谁谁应该坐
哪个座位。另一台机器按调度的结果来收钱，出票据和记录。第二台机
器用常规数据库系统，保证不出错，数据也不掉。
做调度的机器出了问题，有的人买票请求就可能被丢掉了，但不会被收
钱。第一台机器重启后，从第二台机器里拿来记录，重建自己的记录，
搞清楚哪些座位的哪些区间是空闲的，再开始调度。这样说对吧？ |
|
T********i
发帖数: 2416 | 35 连调度都不做。只是一个计数器告诉你买到票了。
确定买到票了，再由另外机器分座位都行。
你可以想象3台单机串联，只有第一台做决定，其它的只更新状态，前后传递消息。 |
|
c****3
发帖数: 10787 | 36 好像计数器更新也是靠消息驱动的。
所以你还得做一个FIFO 的Queue，更新完计数器，把消息放到Queue尾，另一个线程从
Queue头读消息，发给下一个机器。 |
|
T********i
发帖数: 2416 | 37 sequenced message么，我一直都这么说。sequence是关键。因为，第一，有次序，第
二，不能丢。有sequence gap要补上，也就是，fail后sync。 |
|
L*****e
发帖数: 8347 | 38 我理解串联的意思是A-> B-> C-> D-> 下游支付出票。。。
现在B当机了，或者说A到B的网络断了，你的方案A就连到了C？这不叫串联了吧？
传。
★ 发自iPhone App: ChineseWeb 8.2.2 |
|
|
n*****t
发帖数: 22014 | 40 消息串联，物理都在一个 hub 上， 主机之间民主选举谁先上谁后上 |
|
|
|
|
T********i
发帖数: 2416 | 44 其实我也一直用hub。
Arista 7系列。latency 500ns。 |
|
d***a
发帖数: 13752 | 45 如果是这样，我感觉你这个算法会有点问题...但我也不肯定。 |
|
L*****e
发帖数: 8347 | 46 哦，现在基本听明白了，算是把三个月前漏掉的讨论补了补，多谢！
★ 发自iPhone App: ChineseWeb 8.2.2 |
|
T********i
发帖数: 2416 | 47 其实，双向都是sequenced message。只要最后一台剩下，consistency就有保障。
我这里，最后一台是支付系统。
前面还要留一台我的计数器机才能提供服务。而且，支付系统挂了，我的计数器机里还
有journal log。 |
|
d***a
发帖数: 13752 | 48 构思是不错，感觉还可以简化，简单的可靠度高，对吧。 |
|
T********i
发帖数: 2416 | 49 我的设计就是一个messaging system。
如果你能再简化，那当然好。 |
|
s*******y
发帖数: 851 | 50 好虫的方案比老魏的强，老魏的实际上根本不可行，纯粹技术忽悠型。 |
|
