淘寶作為阿里云的經(jīng)典，一直被拿來在四處展示：雙十一交易量有多大，處理能力有多強，還多活云中心架構(gòu)呢......美啊!可5.27傳統(tǒng)行業(yè)的一鏟子，支付寶怎么就歇了?說好的互聯(lián)網(wǎng)云中心呢?說好的多活呢?
多活云中心好啊，但阿里貌似沒想讓太多人知道，多活的實現(xiàn)對于應(yīng)用有特定要求，并不能適合所有應(yīng)用災(zāi)備需求。
談到多活系統(tǒng)，以前流行的名字叫分布式系統(tǒng)，而分布式系統(tǒng)的限制來自于著名的“CAP”理論，即
Consistency(一致性)
Availability(可用性)
Partition tolerance(分區(qū)耐受性)
三部分在系統(tǒng)實現(xiàn)只可同時滿足二點，無法三者兼顧(這個由Eric Brewer 2000年提出，由MIT學(xué)者SethGilbert與Nancy Lynch2002年完成數(shù)學(xué)證明)
CAP理論證明了強一致性交易型系統(tǒng)不適合雙活/多活模式。
這也就是說，淘寶是A+P類型，數(shù)據(jù)沒有強一致性要求的。例如，您雙十一賣鞋，庫存3000雙，由于多站點銷售數(shù)據(jù)不能實時同步，最后賣了5000雙，So What!補2000雙貨好了，大不了退了錢，道個歉，再送個紅包。
這方式您在12306試下?3000張票，您賣5000張出去，什么后果?多找2000個座(站)位?哪找去，掛票都沒地!退票?那2000個人不得去鐵道部堵門去!
阿里一直拿它和12306的合作說事兒，您看仔細了，余票查詢系統(tǒng)，是查詢!
還有銀行，賬戶里有3000塊錢，您找?guī)兹送瑫r取去，能讓你每人取出3000塊來嗎?(要真取出來，還是趕緊主動還了吧，咱這兒規(guī)矩，你懂的)
支付寶也不傻啊!淘寶可以多賣2000雙鞋，支付寶不能讓你賬戶上有3000塊，花出去5000塊啊。因此平時支付寶主數(shù)據(jù)庫就在杭州一地呆著，其他地兒哪也不去。什么雙活，多活，那是淘寶的事，支付寶就在杭州想靜靜。
后來人家一鏟子下來，沒辦法，災(zāi)備吧，同城沒做雙活呀，往深圳搬吧。災(zāi)備之前，您得把備份中心的數(shù)據(jù)一致性做好了吧，親們的賬戶里既不能少一分錢，更不能多一分錢。
這就花時間了，因為誰知道那一鏟子下來的瞬間，有多少筆交易沒同步到異地備份中心去啊!(如果您有個同城的災(zāi)備，用了諸如IBM GDPS/PPRC，OracleRAC，或VMware VSC/EMC VPLEX類似的東東，就不用這么擔心了一致性問題了。不過可惜，去IOE了)
說句實際的，保證數(shù)據(jù)一致性不出差錯，憑著人體智能，支付寶在差不多兩個小時做到異地恢復(fù)，這已經(jīng)相當快的嘍。
網(wǎng)傳攜程宕機1小時損失100多萬美元，支付寶一小時損失多少，不知道，肯定比攜程多得多。但對阿里來說，錢是小事情，聲譽上的損失是沒法拿錢算的。
想想看，那么多年了，為毛銀行一直都在搞兩地三中心啊? 所以，跟錢有關(guān)的事兒，您就別信什么互聯(lián)網(wǎng)多活了，踏踏實實做好數(shù)據(jù)同步和災(zāi)備吧。
轉(zhuǎn)型的最終目的 -提質(zhì)降本增效
分享到微信 ×
打開微信，點擊底部的“發(fā)現(xiàn)”，
使用“掃一掃”即可將網(wǎng)頁分享至朋友圈。