一、背景

自2008年雙十一以來，在每年雙十一超大規(guī)模流量的沖擊上，螞蟻金服都會不斷突破現(xiàn)有技術的極限。2010年雙11的支付峰值為2萬筆/分鐘，全天1280萬筆支付，這個數(shù)字到2017雙11時變?yōu)榱?5.6萬筆/秒，全天14.8億筆。在如此之大的支付TPS背后除了削峰等錦上添花的應用級優(yōu)化，最解渴最實質的招數(shù)當數(shù)基于分庫分表的單元化了，螞蟻技術稱之為LDC（邏輯數(shù)據(jù)中心）。

• 支付寶海量支付背后最解渴的設計是啥？換句話說，實現(xiàn)支付寶高TPS的最關鍵的設計是啥？

• LDC是啥？LDC怎么實現(xiàn)異地多活和異地災備的？

• CAP魔咒到底是啥？P到底怎么理解？

• 什么是腦裂？跟CAP又是啥關系？

• 什么是PAXOS，它解決了啥問題？

• PAXOS和CAP啥關系？

• PAXOS可以逃脫CAP魔咒么？

• Oceanbase能逃脫CAP魔咒么？

LDC（logic data center)是相對于傳統(tǒng)的（Internet Data Center-IDC）提出的，邏輯數(shù)據(jù)中心所表達的中心思想是無論物理結構如何的分布，整個數(shù)據(jù)中心在邏輯上是協(xié)同和統(tǒng)一的。這句話暗含的是強大的體系設計，分布式系統(tǒng)的挑戰(zhàn)就在于整體協(xié)同工作（可用性，分區(qū)容忍性）和統(tǒng)一（一致性）。關注公眾號互聯(lián)網(wǎng)架構師，回復關鍵字2T，獲取最新架構視頻

小結：分庫分表解決的最大痛點是數(shù)據(jù)庫單點瓶頸，這個瓶頸的產(chǎn)生是由現(xiàn)代二進制數(shù)據(jù)存儲體系決定的（即I/O速度）。
單元化只是分庫分表后系統(tǒng)部署的一種方式，這種部署模式在災備方面也發(fā)揮了極大的優(yōu)勢。

2.1 系統(tǒng)架構演化史

??

??

??

?

思考一下：
應用間其實也存在交互（比如A轉賬給B），也就意味著，應用不需要鏈接其他的數(shù)據(jù)庫了，但是還需要鏈接其他應用。如果是常見的RPC框架如dubbo等，使用的是TCP/IP協(xié)議，那么等同于把之前與數(shù)據(jù)庫建立的鏈接，換成與其他應用之間的鏈接了。為啥這樣就消除瓶頸了呢？首先由于合理的設計，應用間的數(shù)據(jù)交互并不巨量，其次應用間的交互可以共享TCP鏈接，比如A->B之間的Socket鏈接可以被A中的多個線程復用，而一般的數(shù)據(jù)庫如MySQL則不行，所以MySQL才需要數(shù)據(jù)庫鏈接池。

?

下圖為一個三地五機房的部署方式。
?

• RZone(Region Zone)：直譯可能有點反而不好理解。實際上就是所有可以分庫分表的業(yè)務系統(tǒng)整體部署的最小單元。每個RZone連上數(shù)據(jù)庫就可以撐起一片天空，把業(yè)務跑的溜溜的。
• GZone(Global Zone)：全局單元，意味著全局只有一份。部署了不可拆分的數(shù)據(jù)和服務，比如系統(tǒng)配置等。實際情況下，GZone異地也會部署，不過僅是用于災備，同一時刻，只有一地GZone進行全局服務。GZone一般被RZone依賴，提供的大部分是讀取服務。
• CZone(City Zone)：顧名思義，這是以城市為單位部署的單元。同樣部署了不可拆分的數(shù)據(jù)和服務，比如用戶賬號服務，客戶信息服務等。理論上CZone會被RZone以比訪問GZone高很多的頻率進行訪問。CZone是基于特定的GZone場景進行優(yōu)化的一種單元，它把GZone中有些有著”寫讀時間差現(xiàn)象”的數(shù)據(jù)和服務進行了的單獨部署，這樣RZone只需要訪問本地的CZone即可，而不是訪問異地的GZone。

• 用戶流水型數(shù)據(jù)：典型的有用戶的訂單、用戶發(fā)的評論、用戶的行為記錄等。這些數(shù)據(jù)都是用戶行為產(chǎn)生的流水型數(shù)據(jù)，具備天然的用戶隔離性，比如A用戶的App上絕對看不到B用戶的訂單列表。所以此類數(shù)據(jù)非常適合分庫分表后獨立部署服務。
• 用戶間共享型數(shù)據(jù)：這種類型的數(shù)據(jù)又分兩類。一類共享型數(shù)據(jù)是像賬號、個人博客等可能會被所有用戶請求訪問的用戶數(shù)據(jù)，比如A向B轉賬，A給B發(fā)消息，這時候需要確認B賬號是否存在；又比如A想看B的個人博客之類的。另外一類是用戶無關型數(shù)據(jù)，像商品、系統(tǒng)配置（匯率、優(yōu)惠政策）、財務統(tǒng)計等這些非用戶緯度的數(shù)據(jù)，很難說跟具體的某一類用戶掛鉤，可能涉及到所有用戶。比如商品，假設按商品所在地來存放商品數(shù)據(jù)（這需要雙維度分庫分表），那么上海的用戶仍然需要訪問杭州的商品，這就又構成跨地跨zone訪問了，還是達不到單元化的理想狀態(tài)，而且雙維度分庫分表會給整個LDC運維帶來復雜度提升。

注：網(wǎng)上和支付寶內(nèi)部有另外一些分法，比如流水型和狀態(tài)性，有時候還會分為三類：流水型、狀態(tài)型和配置型。個人覺得這些分法雖然嘗試去更高層次的抽象數(shù)據(jù)分類，但實際上邊界很模糊，適得其反。

即便架構師們設計了完美的CRG，但即便在螞蟻的實際應用中，各個系統(tǒng)仍然存在不合理的CRG分類，尤其是CG不分的現(xiàn)象很常見。

三、支付寶單元化的異步多活和災備

3.1、流量挑撥技術探秘簡介

??

RZ0* --> a
RZ1* --> b
RZ2* --> c
RZ3* --> d

3.2、支付寶災備機制

• 同機房單元間災備。
• 同城機房間災備。
• 異地機房間災備。

3.2.1、同機房單元間災備

3.2.2、同城機房間災備

災難發(fā)生可能性相對更小。這種災難發(fā)生的原因一般是機房電線網(wǎng)線被挖斷，或者機房維護人員操作失誤導致的。在這種情況下，就需要人工的制定流量挑撥（切流）方案了。下面我們舉例說明這個過程，如下圖所示為上海的兩個IDC機房。?

RZ0* --> a
RZ1* --> b
RZ2* --> c
RZ3* --> d

RZ0* --> /
RZ1* --> /
RZ2* --> a
RZ2* --> c
RZ3* --> b
RZ3* --> d

[00-24] --> RZ0A(50%),RZOB(50%)
[25-49] --> RZ1A(50%),RZ1B(50%)
[50-74] --> RZ2A(50%),RZ2B(50%)
[75-99] --> RZ3A(50%),RZ3B(50%)

[00-24] --> RZ2A(50%),RZ2B(50%)
[25-49] --> RZ3A(50%),RZ3B(50%)
[50-74] --> RZ2A(50%),RZ2B(50%)
[75-99] --> RZ3A(50%),RZ3B(50%)

這里可以思考下，為何先切數(shù)據(jù)庫映射，再切流量呢？這是因為如果先切流量，意味著大量注定失敗的請求會被打到新的正常單元上去，從而影響系統(tǒng)的穩(wěn)定性（數(shù)據(jù)庫還沒準備好）。

3.2.3、異地機房間災備

4.1、回顧CAP

4.1.1 CAP的定義

• Consistency（一致性），這個理解起來很簡單，就是每時每刻每個節(jié)點上的同一份數(shù)據(jù)都是一致的。這就要求任何更新都是原子的，即要么全部成功，要么全部失敗。想象一下使用分布式事務來保證所有系統(tǒng)的原子性是多么低效的一個操作。
• Availability（可用性），這個可用性看起來很容易理解，但真正說清楚的不多。我更愿意把可用性解釋為：任意時刻系統(tǒng)都可以提供讀寫服務。那么舉個例子，當我們用事務將所有節(jié)點鎖住來進行某種寫操作時，如果某個節(jié)點發(fā)生不可用的情況，會讓整個系統(tǒng)不可用。對于分片式的NoSQL中間件集群（Redis，Memcached）來說，一旦一個分片歇菜了，整個系統(tǒng)的數(shù)據(jù)也就不完整了，讀取宕機分片的數(shù)據(jù)就會沒響應，也就是不可用了。需要說明一點，哪些選擇CP的分布式系統(tǒng)，并不是代表可用性就完全沒有了，只是可用性沒有保障了。為了增加可用性保障，這類中間件往往都提供了”分片集群+復制集”的方案。
• Partition tolerance（分區(qū)容忍性），這個可能也是很多文章都沒說清楚的。P并不是像CA一樣是一個獨立的性質，它依托于CA來進行討論。參考文獻[1]中解釋道：”除非整個網(wǎng)絡癱瘓，否則任何時刻系統(tǒng)都能正常工作”，言下之意是小范圍的網(wǎng)絡癱瘓，節(jié)點宕機，都不會影響整個系統(tǒng)的CA。我感覺這個解釋聽著還是有點懵逼，所以個人更愿意解釋為”當節(jié)點之間網(wǎng)絡不通時（出現(xiàn)網(wǎng)絡分區(qū)），可用性和一致性仍然能得到保障”。從個人角度理解，分區(qū)容忍性又分為”可用性分區(qū)容忍性”和”一致性分區(qū)容忍性”?！背霈F(xiàn)分區(qū)時會不會影響可用性”的關鍵在于”需不需要所有節(jié)點互相溝通協(xié)作來完成一次事務”，不需要的話是鐵定不影響可用性的，慶幸的是應該不太會有分布式系統(tǒng)會被設計成完成一次事務需要所有節(jié)點聯(lián)動，一定要舉個例子的話，全同步復制技術下的Mysql是一個典型案例[2]。”出現(xiàn)分區(qū)時會不會影響一致性”的關鍵則在于出現(xiàn)腦裂時有沒有保證一致性的方案，這對主從同步型數(shù)據(jù)庫（MySQL、SQL Server）是致命的，一旦網(wǎng)絡出現(xiàn)分區(qū)，產(chǎn)生腦裂，系統(tǒng)會出現(xiàn)一份數(shù)據(jù)兩個值的狀態(tài)，誰都不覺得自己是錯的。需要說明的是，正常來說同一局域網(wǎng)內(nèi)，網(wǎng)絡分區(qū)的概率非常低，這也是為啥我們最熟悉的數(shù)據(jù)庫（MySQL、SQL Server等）也是不考慮P的原因。

還有個需要說明的地方，其實分布式系統(tǒng)很難滿足CAP的前提條件是這個系統(tǒng)一定是有讀有寫的，如果只考慮讀，那么CAP很容易都滿足，比如一個計算器服務，接受表達式請求，返回計算結果，搞成水平擴展的分布式，顯然這樣的系統(tǒng)沒有一致性問題，網(wǎng)絡分區(qū)也不怕，可用性也是很穩(wěn)的，所以可以滿足CAP。

4.1.2 CAP分析方法

if(?不存在分區(qū)的可能性?||?分區(qū)后不影響可用性或一致性?||?有影響但考慮了分區(qū)情況-P){
????if(可用性分區(qū)容忍性-A?under?P)）
??????return?"AP";
????else?if(一致性分區(qū)容忍性-C?under?P）
??????return?"CP";
}
else?{??//分區(qū)有影響但沒考慮分區(qū)情況下的容錯
?????if(具備可用性-A?&&?具備一致性-C）{
?????????return?AC;
?????}
}

4.2 水平擴展應用+單數(shù)據(jù)庫實例的CAP分析

這樣的系統(tǒng)天然具有的就是AP（可用性和分區(qū)容忍性），一方面解決了單點導致的低可用性問題，另一方面無論這些水平擴展的機器間網(wǎng)絡是否出現(xiàn)分區(qū)，這些服務器都可以各自提供服務，因為他們之間不需要進行溝通。然而，這樣的系統(tǒng)是沒有一致性可言的，想象一下每個實例都可以往數(shù)據(jù)庫insert和update（注意這里還沒討論到事務），那還不亂了套。

• 分區(qū)容忍性：先看有沒有考慮分區(qū)容忍性，或者分區(qū)后是否會有影響。單臺MySQL無法構成分區(qū)，要么整個系統(tǒng)掛了，要么就活著。
• 可用性分區(qū)容忍性：分區(qū)情況下，假設恰好是該節(jié)點掛了，系統(tǒng)也就不可用了，所以可用性分區(qū)容忍性不滿足。
• 一致性分區(qū)容忍性：分區(qū)情況下，只要可用，單點單機的最大好處就是一致性可以得到保障。
  因此這樣的一個系統(tǒng)，個人認為只是滿足了CP。A有但不出色，從這點可以看出，CAP并不是非黑即白的。包括常說的BASE[3]（最終一致性）方案，其實只是C不出色，但最終也是達到一致性的，BASE在一致性上選擇了退讓。

4.3 水平擴展應用+主從數(shù)據(jù)庫集群的CAP分析

從上圖我可以看到三個數(shù)據(jù)庫實例中只有一個是主庫，其他是從庫。一定程度上，這種架構極大的緩解了”讀可用性”問題，而這樣的架構一般會做讀寫分離來達到更高的”讀可用性”，幸運的是大部分互聯(lián)網(wǎng)場景中讀都占了80%以上，所以這樣的架構能得到較長時間的廣泛應用?！睂懣捎眯浴笨梢酝ㄟ^keepalived[4]這種HA（高可用）框架來保證主庫是活著的，但仔細一想就可以明白，這種方式并沒有帶來性能上的可用性提升。還好，至少系統(tǒng)不會因為某個實例掛了就都不可用了?？捎眯悦銖娺_標了，這時候的CAP分析如下：

• 分區(qū)容忍性：依舊先看分區(qū)容忍性，主從結構的數(shù)據(jù)庫存在節(jié)點之間的通信，他們之間需要通過心跳來保證只有一個Master。然而一旦發(fā)生分區(qū)，每個分區(qū)會自己選取一個新的Master，這樣就出現(xiàn)了腦裂，常見的主從數(shù)據(jù)庫（MySQL，Oracle等）并沒有自帶解決腦裂的方案。所以分區(qū)容忍性是沒考慮的。
• 一致性：不考慮分區(qū)，由于任意時刻只有一個主庫，所以一致性是滿足的。
• 可用性：不考慮分區(qū)，HA機制的存在可以保證可用性，所以可用性顯然也是滿足的。

4.4 螞蟻單元化LDC架構CAP分析

4.4.1 戰(zhàn)勝分區(qū)容忍性

• 某臺機器宕機了，過一會兒又重啟了，看起來就像失聯(lián)了一段時間，像是網(wǎng)絡不可達一樣。
• 異地部署情況下，異地多活意味著每一地都可能會產(chǎn)生數(shù)據(jù)寫入，而異地之間偶爾的網(wǎng)絡延時尖刺（網(wǎng)絡延時曲線圖陡增）、網(wǎng)絡故障都會導致小范圍的網(wǎng)絡分區(qū)產(chǎn)生。前文也提到過，如果一個分布式系統(tǒng)是部署在一個局域網(wǎng)內(nèi)的（一個物理機房內(nèi)），那么個人認為分區(qū)的概率極低，即便有復雜的拓撲，也很少會有在同一個機房里出現(xiàn)網(wǎng)絡分區(qū)的情況。而異地這個概率會大大增高，所以螞蟻的三地五中心必須需要思考這樣的問題，分區(qū)容忍不能丟！同樣的情況還會發(fā)生在不同ISP的機房之間（想象一下你和朋友組隊玩DOTA，他在電信，你在聯(lián)通）。為了應對某一時刻某個機房突發(fā)的網(wǎng)絡延時尖刺活著間歇性失聯(lián)，一個好的分布式系統(tǒng)一定能處理好這種情況下的一致性問題。

如果你了解過比特幣或者區(qū)塊鏈，你就知道區(qū)塊鏈的基礎理論也是PAXOS。區(qū)塊鏈借助PAXOS對最終一致性的貢獻來抵御惡意篡改。而本文涉及的分布式應用系統(tǒng)則是通過PAXOS來解決分區(qū)容忍性。再說本質一點，一個是抵御部分節(jié)點變壞，一個是防范部分節(jié)點失聯(lián)。

4.4.2 OceanBase的CAP分析

個人感覺本文涉及到的知識面確實不少，每個點單獨展開都可以討論半天?；氐轿覀兙o扣的主旨來看，雙十一海量支付背后技術上大快人心的設計到底是啥？我想無非是以下幾點：

• RZone在網(wǎng)絡分區(qū)或災備切換時OB的防腦裂設計（PAXOS）。我們知道RZone是單腦的（讀寫都在一個單元對應的庫），而網(wǎng)絡分區(qū)或者災備時熱切換過程中可能會產(chǎn)生多個腦，OB解決了腦裂情況下的共識問題（PAXOS算法）。
• 基于CZone的本地讀設計。這一點保證了很大一部分有著“寫讀時間差”現(xiàn)象的公共數(shù)據(jù)能被高速本地訪問。
• 剩下的那一丟丟不能本地訪問只能實時訪問GZone的公共配置數(shù)據(jù)，也興不起什么風，作不了什么浪。比如用戶創(chuàng)建這種TPS，不會高到哪里去。再比如對于實時庫存數(shù)據(jù)，可以通過“頁面展示查詢走應用層緩存”+“實際下單時再校驗”的方式減少其GZone調(diào)用量。

參考文獻

---END---
重磅！碼農(nóng)突圍-技術交流群已成立

掃碼可添加碼農(nóng)突圍助手，可申請加入碼農(nóng)突圍大群和細分方向群，細分方向已涵蓋：Java、Python、機器學習、大數(shù)據(jù)、人工智能等群。
一定要備注：開發(fā)方向+地點+學校/公司+昵稱（如Java開發(fā)+上海+拼夕夕+猴子），根據(jù)格式備注，可更快被通過且邀請進群

▲長按加群
推薦閱讀
? ?那個從深圳流水線工人去Google上班程序媛，最近失業(yè)了！
???這款網(wǎng)絡排查工具，堪稱神器！
???面試官扎心一問：數(shù)據(jù)量很大，分頁查詢很慢，有什么優(yōu)化方案？
???太牛了！華中科技大學學霸，201萬頂薪簽約華為，成今年頂薪加入第一人! 網(wǎng)友：我酸了，一輩子的都到達不了
??Java 里的 for (;;) 與 while (true)，哪個更快？
?? 三年，我從語文老師到支付寶技術前端的蛻變
最近面試BAT，整理一份面試資料《Java面試BAT通關手冊》，覆蓋了Java核心技術、JVM、Java并發(fā)、SSM、微服務、數(shù)據(jù)庫、數(shù)據(jù)結構等等。
獲取方式：點“在看”，關注公眾號并回復?BAT?領取，更多內(nèi)容陸續(xù)奉上。
如有收獲，點個在看，誠摯感謝明天見(??ω??)??