支付寶的架構(gòu)到底有多牛逼!還沒看完我就跪了!

來自：CSDN（作者：ITMuch.com）

原文鏈接：

https://blog.csdn.net/lilizhou2008/article/details/103501992

自 2008 年雙 11 以來，在每年雙 11 超大規(guī)模流量的沖擊上，螞蟻金服都會不斷突破現(xiàn)有技術(shù)的極限。2010 年雙 11 的支付峰值為 2 萬筆/分鐘，到 2017 年雙 11 時這個數(shù)字變?yōu)榱?25.6 萬筆/秒。

2018 年雙 11 的支付峰值為 48?萬筆/秒，2019 年雙 11 支付峰值為 54.4 萬筆/秒，創(chuàng)下新紀(jì)錄，是 2009 年第一次雙 11 的 1360?倍。

在如此之大的支付 TPS 背后除了削峰等錦上添花的應(yīng)用級優(yōu)化，最解渴最實質(zhì)的招數(shù)當(dāng)數(shù)基于分庫分表的單元化了，螞蟻技術(shù)稱之為 LDC（邏輯數(shù)據(jù)中心）。

本文不打算討論具體到代碼級的分析，而是嘗試用最簡單的描述來說明其中最大快人心的原理。

我想關(guān)心分布式系統(tǒng)設(shè)計的人都曾被下面這些問題所困擾過：

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

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

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

• 什么是腦裂？跟 CAP 又是啥關(guān)系？

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

• PAXOS 和 CAP 啥關(guān)系？PAXOS 可以逃脫 CAP 魔咒么？

• Oceanbase 能逃脫 CAP 魔咒么？

LDC 和單元化

系統(tǒng)架構(gòu)演化史

最早一般為了業(yè)務(wù)快速上線，所有功能都會放到一個應(yīng)用里，系統(tǒng)架構(gòu)如下圖所示：

隨著業(yè)務(wù)發(fā)展，這個矛盾逐漸轉(zhuǎn)變?yōu)橹饕?，因此工程師們采用了以下架?gòu)：

于是程序員們決定使用主從結(jié)構(gòu)的數(shù)據(jù)庫集群，如下圖所示：

這時候，分庫分表方案出現(xiàn)了：

而一般的數(shù)據(jù)庫如 MySQL 則不行，所以 MySQL 才需要數(shù)據(jù)庫鏈接池。

下圖為一個三地五機(jī)房的部署方式：

螞蟻單元化架構(gòu)實踐

• RZone（Region Zone）：直譯可能有點反而不好理解。實際上就是所有可以分庫分表的業(yè)務(wù)系統(tǒng)整體部署的最小單元。每個 RZone 連上數(shù)據(jù)庫就可以撐起一片天空，把業(yè)務(wù)跑的溜溜的。

• GZone（Global Zone）：全局單元，意味著全局只有一份。部署了不可拆分的數(shù)據(jù)和服務(wù)，比如系統(tǒng)配置等。

  實際情況下，GZone 異地也會部署，不過僅是用于災(zāi)備，同一時刻，只有一地 GZone 進(jìn)行全局服務(wù)。GZone 一般被 RZone 依賴，提供的大部分是讀取服務(wù)。

• CZone（City Zone）：顧名思義，這是以城市為單位部署的單元。同樣部署了不可拆分的數(shù)據(jù)和服務(wù)，比如用戶賬號服務(wù)，客戶信息服務(wù)等。理論上 CZone 會被 RZone 以比訪問 GZone 高很多的頻率進(jìn)行訪問。

  CZone 是基于特定的 GZone 場景進(jìn)行優(yōu)化的一種單元，它把 GZone 中有些有著”寫讀時間差現(xiàn)象”的數(shù)據(jù)和服務(wù)進(jìn)行了的單獨部署，這樣 RZone 只需要訪問本地的 CZone 即可，而不是訪問異地的 GZone。

用戶流水型數(shù)據(jù)：典型的有用戶的訂單、用戶發(fā)的評論、用戶的行為記錄等。

這些數(shù)據(jù)都是用戶行為產(chǎn)生的流水型數(shù)據(jù)，具備天然的用戶隔離性，比如 A 用戶的 App 上絕對看不到 B 用戶的訂單列表。所以此類數(shù)據(jù)非常適合分庫分表后獨立部署服務(wù)。

用戶間共享型數(shù)據(jù)：這種類型的數(shù)據(jù)又分兩類。一類共享型數(shù)據(jù)是像賬號、個人博客等可能會被所有用戶請求訪問的用戶數(shù)據(jù)。

比如 A 向 B 轉(zhuǎn)賬，A 給 B 發(fā)消息，這時候需要確認(rèn) B 賬號是否存在；又比如 A 想看 B 的個人博客之類的。

另外一類是用戶無關(guān)型數(shù)據(jù)，像商品、系統(tǒng)配置（匯率、優(yōu)惠政策）、財務(wù)統(tǒng)計等這些非用戶緯度的數(shù)據(jù)，很難說跟具體的某一類用戶掛鉤，可能涉及到所有用戶。

比如商品，假設(shè)按商品所在地來存放商品數(shù)據(jù)（這需要雙維度分庫分表），那么上海的用戶仍然需要訪問杭州的商品。

這就又構(gòu)成跨地跨 Zone 訪問了，還是達(dá)不到單元化的理想狀態(tài)，而且雙維度分庫分表會給整個 LDC 運維帶來復(fù)雜度提升。

支付寶單元化的異地多活和災(zāi)備

流量挑撥技術(shù)探秘簡介

如下圖所示：

RZone 到 DB 數(shù)據(jù)分區(qū)的訪問這是事先配置好的，上圖中 RZ 和 DB 數(shù)據(jù)分區(qū)的關(guān)系為：

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

①目前支付寶默認(rèn)會按照地域來路由流量，具體的實現(xiàn)承載者是自研的 GLSB（Global Server Load Balancing）：

https://developer.alipay.com/article/1889

• IDC-1?對應(yīng)?cashieridc-1.alipay.com

• IDC-2 對應(yīng)?cashieridc-2.alipay.com

支付寶災(zāi)備機(jī)制

• 同機(jī)房單元間災(zāi)備

• 同城機(jī)房間災(zāi)備

• 異地機(jī)房間災(zāi)備

在這種情況下，就需要人工的制定流量挑撥（切流）方案了。下面我們舉例說明這個過程，如下圖所示為上海的兩個 IDC 機(jī)房。

即將（如上圖所示為初始映射）：

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

變?yōu)椋?/span>

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

然后再修改用戶 ID 和 RZ 之間的映射配置。假設(shè)之前為：

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

那么按照災(zāi)備方案的要求，這個映射配置將變?yōu)椋?/span>

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

螞蟻單元化架構(gòu)的 CAP 分析

回顧 CAP

①CAP 的定義

CAP 原則是指任意一個分布式系統(tǒng)，同時最多只能滿足其中的兩項，而無法同時滿足三項。

Consistency（一致性），這個理解起來很簡單，就是每時每刻每個節(jié)點上的同一份數(shù)據(jù)都是一致的。

這就要求任何更新都是原子的，即要么全部成功，要么全部失敗。想象一下使用分布式事務(wù)來保證所有系統(tǒng)的原子性是多么低效的一個操作。

Availability（可用性），這個可用性看起來很容易理解，但真正說清楚的不多。我更愿意把可用性解釋為：任意時刻系統(tǒng)都可以提供讀寫服務(wù)。

舉個例子，當(dāng)我們用事務(wù)將所有節(jié)點鎖住來進(jìn)行某種寫操作時，如果某個節(jié)點發(fā)生不可用的情況，會讓整個系統(tǒng)不可用。

對于分片式的 NoSQL 中間件集群（Redis，Memcached）來說，一旦一個分片歇菜了，整個系統(tǒng)的數(shù)據(jù)也就不完整了，讀取宕機(jī)分片的數(shù)據(jù)就會沒響應(yīng)，也就是不可用了。

需要說明一點，哪些選擇 CP 的分布式系統(tǒng)，并不是代表可用性就完全沒有了，只是可用性沒有保障了。

為了增加可用性保障，這類中間件往往都提供了”分片集群+復(fù)制集”的方案。

Partition tolerance（分區(qū)容忍性），這個可能也是很多文章都沒說清楚的。P 并不是像 CA 一樣是一個獨立的性質(zhì)，它依托于 CA 來進(jìn)行討論。

參考文獻(xiàn)中的解釋：”除非整個網(wǎng)絡(luò)癱瘓，否則任何時刻系統(tǒng)都能正常工作”，言下之意是小范圍的網(wǎng)絡(luò)癱瘓，節(jié)點宕機(jī)，都不會影響整個系統(tǒng)的 CA。

我感覺這個解釋聽著還是有點懵逼，所以個人更愿意解釋為當(dāng)節(jié)點之間網(wǎng)絡(luò)不通時（出現(xiàn)網(wǎng)絡(luò)分區(qū)），可用性和一致性仍然能得到保障。

從個人角度理解，分區(qū)容忍性又分為“可用性分區(qū)容忍性”和“一致性分區(qū)容忍性”。

出現(xiàn)分區(qū)時會不會影響可用性的關(guān)鍵在于需不需要所有節(jié)點互相溝通協(xié)作來完成一次事務(wù)，不需要的話是鐵定不影響可用性的。

慶幸的是應(yīng)該不太會有分布式系統(tǒng)會被設(shè)計成完成一次事務(wù)需要所有節(jié)點聯(lián)動，一定要舉個例子的話，全同步復(fù)制技術(shù)下的 MySQL 是一個典型案例。

出現(xiàn)分區(qū)時會不會影響一致性的關(guān)鍵則在于出現(xiàn)腦裂時有沒有保證一致性的方案，這對主從同步型數(shù)據(jù)庫（MySQL、SQL Server）是致命的。

一旦網(wǎng)絡(luò)出現(xiàn)分區(qū)，產(chǎn)生腦裂，系統(tǒng)會出現(xiàn)一份數(shù)據(jù)兩個值的狀態(tài)，誰都不覺得自己是錯的。

需要說明的是，正常來說同一局域網(wǎng)內(nèi)，網(wǎng)絡(luò)分區(qū)的概率非常低，這也是為啥我們最熟悉的數(shù)據(jù)庫（MySQL、SQL Server 等）也是不考慮 P 的原因。

下圖為 CAP 之間的經(jīng)典關(guān)系圖：

②CAP 分析方法

先說下 CA 和 P 的關(guān)系，如果不考慮 P 的話，系統(tǒng)是可以輕松實現(xiàn) CA 的。

而 P 并不是一個單獨的性質(zhì)，它代表的是目標(biāo)分布式系統(tǒng)有沒有對網(wǎng)絡(luò)分區(qū)的情況做容錯處理。

以下是個人總結(jié)的分析一個分布式系統(tǒng) 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;
?????}
}

水平擴(kuò)展應(yīng)用+單數(shù)據(jù)庫實例的 CAP?分析

也就是同一個應(yīng)用啟動了多個實例，連接著相同的數(shù)據(jù)庫（為了簡化問題，先不考慮數(shù)據(jù)庫是否單點），如下圖所示：

• 一方面解決了單點導(dǎo)致的低可用性問題。

• 另一方面無論這些水平擴(kuò)展的機(jī)器間網(wǎng)絡(luò)是否出現(xiàn)分區(qū)，這些服務(wù)器都可以各自提供服務(wù)，因為他們之間不需要進(jìn)行溝通。

• 分區(qū)容忍性：先看有沒有考慮分區(qū)容忍性，或者分區(qū)后是否會有影響。單臺 MySQL 無法構(gòu)成分區(qū)，要么整個系統(tǒng)掛了，要么就活著。

• 可用性分區(qū)容忍性：分區(qū)情況下，假設(shè)恰好是該節(jié)點掛了，系統(tǒng)也就不可用了，所以可用性分區(qū)容忍性不滿足。

• 一致性分區(qū)容忍性：分區(qū)情況下，只要可用，單點單機(jī)的最大好處就是一致性可以得到保障。

水平擴(kuò)展應(yīng)用+主從數(shù)據(jù)庫集群的CAP分析

于是如下圖所示的模式成為了當(dāng)下大部分中小公司所使用的架構(gòu)：

• 分區(qū)容忍性：依舊先看分區(qū)容忍性，主從結(jié)構(gòu)的數(shù)據(jù)庫存在節(jié)點之間的通信，他們之間需要通過心跳來保證只有一個 Master。

  然而一旦發(fā)生分區(qū)，每個分區(qū)會自己選取一個新的 Master，這樣就出現(xiàn)了腦裂，常見的主從數(shù)據(jù)庫（MySQL，Oracle 等）并沒有自帶解決腦裂的方案。所以分區(qū)容忍性是沒考慮的。

• 一致性：不考慮分區(qū)，由于任意時刻只有一個主庫，所以一致性是滿足的。

• 可用性：不考慮分區(qū)，HA 機(jī)制的存在可以保證可用性，所以可用性顯然也是滿足的。

螞蟻單元化 LDC 架構(gòu) CAP 分析

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

在討論螞蟻 LDC 架構(gòu)的 CAP 之前，我們再來想想分區(qū)容忍性有啥值得一提的，為啥很多大名鼎鼎的 BASE（最終一致性）體系系統(tǒng)都選擇損失實時一致性，而不是丟棄分區(qū)容忍性呢？

某臺機(jī)器宕機(jī)了，過一會兒又重啟了，看起來就像失聯(lián)了一段時間，像是網(wǎng)絡(luò)不可達(dá)一樣。

異地部署情況下，異地多活意味著每一地都可能會產(chǎn)生數(shù)據(jù)寫入，而異地之間偶爾的網(wǎng)絡(luò)延時尖刺（網(wǎng)絡(luò)延時曲線圖陡增）、網(wǎng)絡(luò)故障都會導(dǎo)致小范圍的網(wǎng)絡(luò)分區(qū)產(chǎn)生。

前文也提到過，如果一個分布式系統(tǒng)是部署在一個局域網(wǎng)內(nèi)的（一個物理機(jī)房內(nèi)），那么個人認(rèn)為分區(qū)的概率極低，即便有復(fù)雜的拓?fù)?，也很少會有在同一個機(jī)房里出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況。

而異地這個概率會大大增高，所以螞蟻的三地五中心必須需要思考這樣的問題，分區(qū)容忍不能丟！

同樣的情況還會發(fā)生在不同 ISP 的機(jī)房之間（想象一下你和朋友組隊玩 DOTA，他在電信，你在聯(lián)通）。

為了應(yīng)對某一時刻某個機(jī)房突發(fā)的網(wǎng)絡(luò)延時尖刺活著間歇性失聯(lián)，一個好的分布式系統(tǒng)一定能處理好這種情況下的一致性問題。

下面是一段摘自維基百科的 PAXOS 定義：

Paxos is a family of protocols for solving consensus in a network of unreliable processors (that is, processors that may fail).

以下摘自維基百科：

Paxos is a family of protocols for solving consensus in a network of unreliable processors (that is, processors that may fail).Quorums express the safety (or consistency) properties of Paxos by ensuring at least some surviving processor retains knowledge of the results.

②OceanBase 的 CAP 分析

上文提到過，單元化架構(gòu)中的成千山萬的應(yīng)用就像是計算器，本身無 CAP 限制，其 CAP 限制下沉到了其數(shù)據(jù)庫層，也就是螞蟻自研的分布式數(shù)據(jù)庫 OceanBase（本節(jié)簡稱 OB）。

下面我們舉個馬老師改英文名的例子來說明 OB 設(shè)計的精妙之處：

假設(shè)數(shù)據(jù)庫按照用戶 ID 分庫分表，馬老師的用戶 ID 對應(yīng)的數(shù)據(jù)段在 [0-9]，開始由單元 A 負(fù)責(zé)數(shù)據(jù)寫入。

假如馬老師（用戶 ID 假設(shè)為 000）正在用支付寶 App 修改自己的英文名，馬老師一開始打錯了，打成了 Jason Ma，A 單元收到了這個請求。

這時候發(fā)生了分區(qū)（比如 A 網(wǎng)絡(luò)斷開了），我們將單元 A 對數(shù)據(jù)段 [0,9] 的寫入權(quán)限轉(zhuǎn)交給單元 B（更改映射），馬老師這次寫對了，為 Jack Ma。

而在網(wǎng)絡(luò)斷開前請求已經(jīng)進(jìn)入了 A，寫權(quán)限轉(zhuǎn)交給單元 B 生效后，A 和 B 同時對 [0,9] 數(shù)據(jù)段進(jìn)行寫入馬老師的英文名。

假如這時候都允許寫入的話就會出現(xiàn)不一致，A 單元說我看到馬老師設(shè)置了 Jason Ma，B 單元說我看到馬老師設(shè)置了 Jack Ma。

然而這種情況不會發(fā)生的，A 提議說我建議把馬老師的英文名設(shè)置為 Jason Ma 時，發(fā)現(xiàn)沒人回應(yīng)它。

因為出現(xiàn)了分區(qū)，其他節(jié)點對它來說都是不可達(dá)的，所以這個提議被自動丟棄，A 心里也明白是自己分區(qū)了，會有主分區(qū)替自己完成寫入任務(wù)的。

同樣的，B 提出了將馬老師的英文名改成 Jack Ma 后，大部分節(jié)點都響應(yīng)了，所以 B 成功將 Jack Ma 寫入了馬老師的賬號記錄。

假如在寫權(quán)限轉(zhuǎn)交給單元 B 后 A 突然恢復(fù)了，也沒關(guān)系，兩筆寫請求同時要求獲得 (N/2)+1 個節(jié)點的事務(wù)鎖，通過 no-wait 設(shè)計，在 B 獲得了鎖之后，其他爭搶該鎖的事務(wù)都會因為失敗而回滾。

• 分區(qū)容忍性：OB 節(jié)點之間是有互相通信的（需要相互同步數(shù)據(jù)），所以存在分區(qū)問題，OB 通過僅同步到部分節(jié)點來保證可用性。這一點就說明 OB 做了分區(qū)容錯。

• 可用性分區(qū)容忍性：OB 事務(wù)只需要同步到?（N/2)+1 個節(jié)點，允許其余的一小半節(jié)點分區(qū)（宕機(jī)、斷網(wǎng)等），只要 (N/2)+1 個節(jié)點活著就是可用的。

  極端情況下，比如 5 個節(jié)點分成 3 份（2:2:1），那就確實不可用了，只是這種情況概率比較低。

• 一致性分區(qū)容忍性：分區(qū)情況下意味著部分節(jié)點失聯(lián)了，一致性顯然是不滿足的。但通過共識算法可以保證當(dāng)下只有一個值是合法的，并且最終會通過節(jié)點間的同步達(dá)到最終一致性。

結(jié)語

• 基于用戶分庫分表的 RZone 設(shè)計。每個用戶群獨占一個單元給整個系統(tǒng)的容量帶來了爆發(fā)式增長。

• RZone 在網(wǎng)絡(luò)分區(qū)或災(zāi)備切換時 OB 的防腦裂設(shè)計（PAXOS）。我們知道 RZone 是單腦的（讀寫都在一個單元對應(yīng)的庫），而網(wǎng)絡(luò)分區(qū)或者災(zāi)備時熱切換過程中可能會產(chǎn)生多個腦，OB 解決了腦裂情況下的共識問題（PAXOS 算法）。

• 基于 CZone 的本地讀設(shè)計。這一點保證了很大一部分有著“寫讀時間差”現(xiàn)象的公共數(shù)據(jù)能被高速本地訪問。

• 剩下的那一丟丟不能本地訪問只能實時訪問 GZone 的公共配置數(shù)據(jù)，也興不起什么風(fēng)，作不了什么浪。

  比如用戶創(chuàng)建這種 TPS，不會高到哪里去。再比如對于實時庫存數(shù)據(jù)，可以通過“頁面展示查詢走應(yīng)用層緩存”+“實際下單時再校驗”的方式減少其 GZone 調(diào)用量。

參考文獻(xiàn)：

• Practice of Cloud System Administration, The: DevOps and SRE Practices for Web Services, Volume 2. Thomas A. Limoncelli, Strata R. Chalup, Christina J. Hogan.

• MySQL 5.7?半同步復(fù)制技術(shù)

  https://www.cnblogs.com/zero-gg/p/9057092.html

• BASE 理論分析

  https://www.jianshu.com/p/f6157118e54b

• Keepalived

  https://baike.baidu.com/item/Keepalived/10346758?fr=aladdin

• PAXOS

  https://en.wikipedia.org/wiki/Paxos_(computer_science)

• OceanBase 支撐 2135 億成交額背后的技術(shù)原理

  https://www.cnblogs.com/antfin/articles/10299396.html

• Backup

  https://en.wikipedia.org/wiki/Backup

推薦閱讀：

• 牛X，試用了下GitHub上22k Star的第一搶票神器，3秒鐘搶到！
  

• 如何將Azure SQL 數(shù)據(jù)庫還原到本地數(shù)據(jù)庫中
  

• 你能說出 Kafka 這些原理嗎
  

• 我是怎么讀源碼的，授之以漁
  

喜歡我可以給我設(shè)為星標(biāo)哦

好文章，我?在看?