異地多活實(shí)際可行性有多強(qiáng)？支付寶故障引熱議

wwwsq

wwwsq 發(fā)表于 2015-06-10 13:06
我可以很肯定的說，支付寶沒有實(shí)現(xiàn)強(qiáng)一致性。一定是裁剪過的相對一致性，在可以承受的范圍內(nèi)允許數(shù)據(jù) ...

支付寶的交易，一定有一個(gè)狀態(tài)是‘支付中’。這個(gè)狀態(tài)如果持續(xù)時(shí)間太長，那么這筆交易就會成為一筆掛賬，一定會觸發(fā)某種對賬機(jī)制。

‘支付中’的狀態(tài)如果足夠短，用戶就會沒感覺。

wwwsq

fengzhanhai 發(fā)表于 2015-06-08 17:28
回復(fù) 111# bbjmmj
你必須要承認(rèn)一個(gè)問題，對于支付寶這個(gè)系統(tǒng)是一個(gè)實(shí)時(shí)性的OLTP系統(tǒng)，而非你說的最終一致 ...

消息隊(duì)列總體上來說是個(gè)謊言，你以為它承諾了什么，其實(shí)它什么也沒承諾。

bbjmmj

wwwsq 發(fā)表于 2015-06-10 13:18
阿里早就建了自己的骨干網(wǎng)。

但是它還沒有膽量用INFINIBAND做骨干。
阿里的網(wǎng)管我們不能太高看他，斷網(wǎng)就切數(shù)據(jù)中心么？有東西未必就能用得好。

bbjmmj

wwwsq 發(fā)表于 2015-06-10 13:06
我可以很肯定的說，支付寶沒有實(shí)現(xiàn)強(qiáng)一致性。一定是裁剪過的相對一致性，在可以承受的范圍內(nèi)允許數(shù)據(jù) ...

這個(gè)絕對可以肯定，淘寶秒殺，都能下單，但是最早付款成功的那個(gè)人才能買走那唯一一件商品�？梢栽试S一定的不一致。
銀行也不是強(qiáng)一致的，要不怎么有“沖賬”這個(gè)活兒呢。
要看業(yè)務(wù)流程了。

bbjmmj

回復(fù) 130# wwwsq


    一致性不難實(shí)現(xiàn)，每種商品的數(shù)量就是個(gè)信號鎖，下單的時(shí)候這個(gè)值減一再讀出，如果大于等于零就可以提交訂單，如果小于零就加一，等待若干毫秒再減一讀出進(jìn)行嘗試，嘗試三遍不成就放棄下單。好像可以不用任何鎖。

stay_sun

回復(fù) 126# bbjmmj


    阿里的團(tuán)隊(duì) 哪里都有  杭州 只是一部分  馬上阿里在 望京建了 一個(gè)大樓

wwwsq

bbjmmj 發(fā)表于 2015-06-10 14:08
回復(fù) 130# wwwsq

http://en.wikipedia.org/wiki/Consistency_model

取決于你說的是哪種一致性。如果是strict consistency那有點(diǎn)難吧？

bbjmmj

wwwsq 發(fā)表于 2015-06-10 17:53
http://en.wikipedia.org/wiki/Consistency_model

取決于你說的是哪種一致性。如果是strict consi ...

電子交易跟一致性沒有必然聯(lián)系，電子交易需要的是數(shù)據(jù)不丟不錯，要求一致的是你，你沒辦法保證不丟不錯，只能拿幾份相同的數(shù)據(jù)糊弄，就像三人成虎。
理論是可以向現(xiàn)實(shí)妥協(xié)的，比如人們常說：理論上講如何如何如何，其實(shí)理論上描述的場景在現(xiàn)實(shí)中根本就是不會存在的。
銀行災(zāi)備都會丟數(shù)據(jù)，過度吹噓理論是主因。

bbjmmj

wwwsq 發(fā)表于 2015-06-10 17:53
http://en.wikipedia.org/wiki/Consistency_model

取決于你說的是哪種一致性。如果是strict consi ...

其實(shí)根本不需要讓技術(shù)去附庸理論，做過網(wǎng)站，就會明白電子交易原理。

bbjmmj

繼續(xù)聊多活。
前面提到一個(gè)MYSQL半同步，半同步狀態(tài)下，有一路SLAVE跟上了，MASTER就會繼續(xù)后面的步驟，也就是去執(zhí)行事務(wù)。我琢磨這么做不夠完美，因?yàn)闆]有冗余，中間可能會出錯，比如這個(gè)搶先同步的SLAVE出了故障，而其它SALVE卻還沒有來得及同步，這個(gè)時(shí)候就可能會丟數(shù)據(jù)，所以我翻了翻源碼，覺得可以對半同步流程做點(diǎn)小改動。
我用的是MARIADB，CENTOS7上帶的是5.5.41，我看的也是5.5.41源碼。
用int ReplSemiSyncMaster::reportReplyBinlog函數(shù)里的can_release_threads做計(jì)數(shù)器，布爾型，改成初值為零的整形，后面if (cmp >= 0) can_release_threads = true改成if (cmp >= 0) can_release_threads++，然后判斷can_release_threads 是不是大于等于2，是則wait_file_name_inited_ = false，再往后if (can_release_threads)改成if (can_release_threads >=2)，這個(gè)2就是達(dá)到同步的SLAVE數(shù)量，我覺得2路就夠了，覺得不夠可以改成3，或者更多。
我自己沒試，只是說了一個(gè)想法。

涉及到的代碼在mariadb-5.5.41/plugin/semisync/semisync_master.cc文件里。前面回帖說到一致性，來了點(diǎn)靈感，兩份一樣的數(shù)據(jù)比較讓人放心。