支付寶的架構到底有多牛逼？
做者丨湯波
來源丨uee.me/cFgQC自 2008 年雙 11 以來，在每一年雙 11 超大規模流量的衝擊上，螞蟻金服都會不斷突破現有技術的極限。2010 年雙 11 的支付峯值爲 2 萬筆/分鐘，到 2017 年雙 11 時這個數字變爲了 25.6 萬筆/秒。html
支付寶海量支付背後最解渴的設計是啥？換句話說，實現支付寶高 TPS 的最關鍵的設計是啥？前端
LDC 是啥？LDC 怎麼實現異地多活和異地災備的？程序員
CAP 魔咒究竟是啥？P 到底怎麼理解？算法
什麼是腦裂？跟 CAP 又是啥關係？數據庫
什麼是 PAXOS，它解決了啥問題？express
PAXOS 和 CAP 啥關係？PAXOS 能夠逃脫 CAP 魔咒麼？後端
Oceanbase 能逃脫 CAP 魔咒麼？緩存
LDC 和單元化服務器
這句話暗含的是強大的體系設計，分佈式系統的挑戰就在於總體協同工做（可用性，分區容忍性）和統一（一致性）。
單元化是大型互聯網系統的必然選擇趨勢，舉個最最通俗的例子來講明單元化。
咱們老是說 TPS 很難提高，確實任何一家互聯網公司（好比淘寶、攜程、新浪）它的交易 TPS 頂多以十萬計量（平均水平），很難往上串了。
這個例子帶給咱們一些思考： 爲啥幾家互聯網公司的 TPS 之和能夠那麼大，服務的用戶數規模也極爲嚇人，而單個互聯網公司的 TPS 卻很難提高？
究其本質，每家互聯網公司都是一個獨立的大型單元，他們各自服務本身的用戶互不干擾。
這就是單元化的基本特性，任何一家互聯網公司，其想要成倍的擴大本身系統的服務能力，都必然會走向單元化之路。
以淘寶舉例，這樣以後，就會有不少個淘寶系統分別爲不一樣的用戶服務，每一個淘寶系統都作到十萬 TPS 的話，N 個這樣的系統就能夠輕鬆作到 N*十萬的 TPS 了。
LDC 實現的關鍵就在於單元化系統架構設計，因此在螞蟻內部，LDC 和單元化是不分家的，這也是不少同窗比較困擾的地方，看似沒啥關係，實則是單元化體系設計成就了 LDC。
系統架構演化史網絡
幾乎任何規模的互聯網公司，都有本身的系統架構迭代和更新，大體的演化路徑都大同小異。
最先通常爲了業務快速上線，全部功能都會放到一個應用裏，系統架構以下圖所示：
隨着業務發展，這個矛盾逐漸轉變爲主要矛盾，所以工程師們採用瞭如下架構：
這是整個公司第一次觸碰到分佈式，也就是對某個應用進行了水平擴容，它將多個微機的計算能力團結了起來，能夠完勝同等價格的中小型機器。
慢慢的，你們發現，應用服務器 CPU 都很正常了，可是仍是有不少慢請求，究其緣由，是由於單點數據庫帶來了性能瓶頸。
因而程序員們決定使用主從結構的數據庫集羣，以下圖所示：
其中大部分讀操做能夠直接訪問從庫，從而減輕主庫的壓力。然而這種方式仍是沒法解決寫瓶頸，寫依舊須要主庫來處理，當業務量量級再次增高時，寫已經變成刻不容緩的待處理瓶
不一樣功能的表放到不一樣的庫裏，通常對應的是垂直拆分（按照業務功能進行拆分），此時通常還對應了微服務化。
這種方法作到極致基本能支撐 TPS 在萬級甚至更高的訪問量了。然而隨着相同應用擴展的越多，每一個數據庫的連接數也巨量增加，這讓數據庫自己的資源成爲了瓶頸。
這個問題產生的本質是全量數據無差異的分享了全部的應用資源，好比 A 用戶的請求在負載均衡的分配下可能分配到任意一個應用服務器上，於是全部應用所有都要連接 A 用戶所在的分庫，數據庫鏈接數就變成笛卡爾乘積了。
在本質點說，這種模式的資源隔離性還不夠完全。要解決這個問題，就須要把識別用戶分庫的邏輯往上層移動，從數據庫層移動到路由網關層。
這樣一來，從應用服務器 a 進來的來自 A 客戶的全部請求必然落庫到 DB-A，所以 a 也不用連接其餘的數據庫實例了，這樣一個單元化的雛形就誕生了。
螞蟻單元化架構實踐
螞蟻支付寶應該是國內最大的支付工具，其在雙 11 等活動日當日的支付 TPS 可達幾十萬級，將來這個數字可能會更大，這決定了螞蟻單元化架構從容量要求上看必然從單機房走向多機房。
RZone（Region Zone）：直譯可能有點反而很差理解。實際上就是全部能夠分庫分表的業務系統總體部署的最小單元。每一個 RZone 連上數據庫就能夠撐起一片天空，把業務跑的溜溜的。
GZone（Global Zone）：全局單元，意味着全局只有一份。部署了不可拆分的數據和服務，好比系統配置等。
實際狀況下，GZone 異地也會部署，不過僅是用於災備，同一時刻，只有一地 GZone 進行全局服務。GZone 通常被 RZone 依賴，提供的大部分是讀取服務。
CZone（City Zone）：顧名思義，這是以城市爲單位部署的單元。一樣部署了不可拆分的數據和服務，好比用戶帳號服務，客戶信息服務等。理論上 CZone 會被 RZone 以比訪問 GZone 高不少的頻率進行訪問。
CZone 是基於特定的 GZone 場景進行優化的一種單元，它把 GZone 中有些有着」寫讀時間差現象」的數據和服務進行了的單獨部署，這樣 RZone 只須要訪問本地的 CZone 便可，而不是訪問異地的 GZone。
下面咱們來根據數據性質的不一樣來解釋支付寶的 CRG 架構。當下幾乎全部互聯網公司的分庫分表規則都是根據用戶 ID 來制定的。
再來分析下 GZone，GZone 之因此只能單地部署，是由於其數據要求被全部用戶共享，沒法分庫分表，而多地部署會帶來由異地延時引發的不一致。
這時螞蟻架構師們問了本身一個問題——難道全部數據受不了延時麼？ 這個問題像是打開了新世界的大門，經過對 RZone 已有業務的分析，架構師們發現 80% 甚至更高的場景下，數據更新後都不要求立馬被讀取到。
也就是上文提到的」寫讀時間差現象」，那麼這就好辦了，對於這類數據，咱們容許每一個地區的 RZone 服務直接訪問本地，爲了給這些 RZone 提供這些數據的本地訪問能力，螞蟻架構師設計出了 CZone。
在 CZone 的場景下，寫請求通常從 GZone 寫入公共數據所在庫，而後同步到整個 OB 集羣，而後由 CZone 提供讀取服務。好比支付寶的會員服務就是如此。
支付寶單元化的異地多活和災備
流量唆使技術探祕簡介
也不知道從哪一天開始，冷備在主備系統裏表明了這臺備用機器是關閉狀態的，只有主服務器掛了以後，備服務器纔會被啓動。
爲了作到每一個單元訪問哪些用戶變成可配置，支付寶要求單元化管理系統具有流量到單元的可配置以及單元到 DB 的可配置能力。
其中 Spanner 是螞蟻基於 Nginx 自研的反向代理網關，也很好理解，有些請求咱們但願在反向代理層就被轉發至其餘 IDC 的 Spanner 而無需進入後端服務，如圖箭頭 2 所示。
那麼對於應該在本 IDC 處理的請求，就直接映射到對應的 RZ 便可，如圖箭頭 1。
進入後端服務後，理論上若是請求只是讀取用戶流水型數據，那麼通常不會再進行路由了。
然而，對於有些場景來講，A 用戶的一個請求可能關聯了對 B 用戶數據的訪問，好比 A 轉帳給 B，A 扣完錢後要調用帳務系統去增長 B 的餘額。
這時候就涉及到再次的路由，一樣有兩個結果：跳轉到其餘 IDC（如圖箭頭 3）或是跳轉到本 IDC 的其餘 RZone（如圖箭頭 4）。
RZ0* --> a
RZ1* --> b
RZ2* --> c
RZ3* --> d
①目前支付寶默認會按照地域來路由流量，具體的實現承載者是自研的 GLSB（Global Server Load Balancing）：
https://developer.alipay.com/article/1889
你們本身搞過網站的化應該知道大部分 DNS 服務商的地址都是靠人去配置的，GLSB 屬於動態配置域名的系統，網上也有比較火的相似產品，好比花生殼之類（建過私站的同窗應該很熟悉）的。
②好了，到此爲止，用戶的請求來到了 IDC-1 的 Spanner 集羣服務器上，Spanner 從內存中讀取到了路由配置，知道了這個請求的主體用戶 C 所屬的 RZ3* 再也不本 IDC，因而直接轉到了 IDC-2 進行處理。
③進入 IDC-2 以後，根據流量配比規則，該請求被分配到了 RZ3B 進行處理。
④RZ3B 獲得請求後對數據分區 c 進行訪問。
⑤處理完畢後原路返回。
你們應該發現問題所在了，若是再來一個這樣的請求，豈不是每次都要跨地域進行調用和返回體傳遞？
確實是存在這樣的問題的，對於這種問題，支付寶架構師們決定繼續把決策邏輯往用戶終端推移。
好比，每一個 IDC 機房都會有本身的域名（真實狀況可能不是這樣命名的）:
IDC-1 對應 cashieridc-1.alipay.com
IDC-2 對應 cashieridc-2.alipay.com
支付寶災備機制
支付寶 LDC 架構下的災備有三個層次：
同機房單元間災備
同城機房間災備
異地機房間災備
從上節裏的圖中能夠看到每組 RZ 都有 A，B 兩個單元，這就是用來作同機房災備的，而且 AB 之間也是雙活雙備的。
同城機房間災備： 災難發生可能性相對更小。這種災難發生的緣由通常是機房電線網線被挖斷，或者機房維護人員操做失誤致使的。
在這種狀況下，就須要人工的制定流量唆使（切流）方案了。下面咱們舉例說明這個過程，以下圖所示爲上海的兩個 IDC 機房。
整個切流配置過程分兩步，首先須要將陷入災難的機房中 RZone 對應的數據分區的訪問權配置進行修改。
那麼首先要作的是把數據分區 a，b 對應的訪問權從 RZ0 和 RZ1 收回，分配給 RZ2 和 RZ3。
即將（如上圖所示爲初始映射）：
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%)
實際狀況中，整個過程並非災難發生後再去作的，整個切換的流程會以預案配置的形式事先準備好，推送給每一個流量唆使客戶端（集成到了全部的服務和 Spanner 中）。
異地機房間災備： 這個基本上跟同城機房間災備一致（這也是單元化的優勢），再也不贅述。
螞蟻單元化架構的 CAP 分析
回顧 CAP
①CAP 的定義
CAP 原則是指任意一個分佈式系統，同時最多隻能知足其中的兩項，而沒法同時知足三項。
所謂的分佈式系統，說白了就是一件事一我的作的，如今分給好幾我的一塊兒幹。
咱們先簡單回顧下 CAP 各個維度的含義：
②CAP 分析方法
先說下 CA 和 P 的關係，若是不考慮 P 的話，系統是能夠輕鬆實現 CA 的。
而 P 並非一個單獨的性質，它表明的是目標分佈式系統有沒有對網絡分區的狀況作容錯處理。
若是作了處理，就必定是帶有 P 的，接下來再考慮分區狀況下到底選擇了 A 仍是 C。 因此分析 CAP，建議先肯定有沒有對分區狀況作容錯處理。
if( 不存在分區的可能性 || 分區後不影響可用性或一致性 || 有影響但考慮了分區狀況-P){
if(可用性分區容忍性-A under P)）
return "AP";
else if(一致性分區容忍性-C under P）
return "CP";
}
else{ //分區有影響但沒考慮分區狀況下的容錯
if(具有可用性-A && 具有一致性-C）{
return AC;
}
}
水平擴展應用+單數據庫實例的 CAP 分析
另一方面，單體應用因爲業務功能複雜，對機器的要求也逐漸變高，普通的微機沒法知足這種性能和容量的要求。
因此要拆！還在 IBM 大賣小型商用機的年代，阿里巴巴就提出要以分佈式微機替代小型機。
因此咱們發現，分佈式系統解決的最大的痛點，就是單體單機系統的可用性問題。
要想高可用，必須分佈式。一家互聯網公司的發展之路上，第一次與分佈式相遇應該都是在單體應用的水平擴展上。
也就是同一個應用啓動了多個實例，鏈接着相同的數據庫（爲了簡化問題，先不考慮數據庫是否單點），以下圖所示：
一方面解決了單點致使的低可用性問題。
另外一方面不管這些水平擴展的機器間網絡是否出現分區，這些服務器均可以各自提供服務，由於他們之間不須要進行溝通。
然而，這樣的系統是沒有一致性可言的，想象一下每一個實例均可以往數據庫 insert 和 update（注意這裏還沒討論到事務），那還不亂了套。
單點就像單機同樣(本例子中不考慮從庫模式)，理論上就不叫分佈式了，若是必定要分析其 CAP 的話， 根據上面的步驟分析過程應該是這樣的：
分區容忍性：先看有沒有考慮分區容忍性，或者分區後是否會有影響。單臺 MySQL 沒法構成分區，要麼整個系統掛了，要麼就活着。
可用性分區容忍性：分區狀況下，假設剛好是該節點掛了，系統也就不可用了，因此可用性分區容忍性不知足。
一致性分區容忍性：分區狀況下，只要可用，單點單機的最大好處就是一致性能夠獲得保障。
包括常說的 BASE （最終一致性）方案，其實只是 C 不出色，但最終也是達到一致性的，BASE 在一致性上選擇了退讓。
想象一下，若是沒有數據庫層，而是應用本身來保障數據一致性，那麼這樣的應用之間就涉及到狀態的同步和交互了，ZooKeeper 就是這麼一個典型的例子。
水平擴展應用+主從數據庫集羣的CAP分析
現實中，技術人員們也會很快發現這種架構的不合理性——可用性過低了。
寫可用性能夠經過 Keepalived 這種 HA（高可用）框架來保證主庫是活着的，但仔細一想就能夠明白，這種方式並無帶來性能上的可用性提高。 還好，至少系統不會由於某個實例掛了就都不可用了。
分區容忍性：依舊先看分區容忍性，主從結構的數據庫存在節點之間的通訊，他們之間須要經過心跳來保證只有一個 Master。
然而一旦發生分區，每一個分區會本身選取一個新的 Master，這樣就出現了腦裂，常見的主從數據庫（MySQL，Oracle 等）並無自帶解決腦裂的方案。因此分區容忍性是沒考慮的。
一致性：不考慮分區，因爲任意時刻只有一個主庫，因此一致性是知足的。
可用性：不考慮分區，HA 機制的存在能夠保證可用性，因此可用性顯然也是知足的。
還真有嘗試經過預先設置規則來解決這種多主庫帶來的一致性問題的系統，好比 CouchDB，它經過版本管理來支持多庫寫入，在其仲裁階段會經過 DBA 配置的仲裁規則（也就是合併規則，好比誰的時間戳最晚誰的生效）進行自動仲裁（自動合併），從而保障最終一致性（BASE），自動規則沒法合併的狀況則只能依賴人工決策了。
螞蟻單元化 LDC 架構 CAP 分析
①打敗分區容忍性
在討論螞蟻 LDC 架構的 CAP 以前，咱們再來想一想分區容忍性有啥值得一提的，爲啥不少大名鼎鼎的 BASE（最終一致性）體系系統都選擇損失實時一致性，而不是丟棄分區容忍性呢？
分區的產生通常有兩種狀況：
異地部署狀況下， 異地多活意味着每一地均可能會產生數據寫入，而異地之間偶爾的網絡延時尖刺（網絡延時曲線圖陡增）、網絡故障都會致使小範圍的網絡分區產生。
前文也提到過，若是一個分佈式系統是部署在一個局域網內的（一個物理機房內），那麼我的認爲分區的機率極低，即使有複雜的拓撲，也不多會有在同一個機房裏出現網絡分區的狀況。
而異地這個機率會大大增高，因此螞蟻的三地五中心必須須要思考這樣的問題，分區容忍不能丟！
一樣的狀況還會發生在不一樣 ISP 的機房之間（想象一下你和朋友組隊玩 DOTA，他在電信，你在聯通）。
爲了應對某一時刻某個機房突發的網絡延時尖刺活着間歇性失聯，一個好的分佈式系統必定能處理好這種狀況下的一致性問題。
那麼螞蟻是怎麼解決這個問題的呢？咱們在上文討論過，其實 LDC 機房的各個單元都由兩部分組成：負責業務邏輯計算的應用服務器和負責數據持久化的數據庫。
想必螞蟻的讀者大概猜到下面的討論重點了——OceanBase（下文簡稱OB），中國第一款自主研發的分佈式數據庫，一時間也確實得到了不少光環。
首先，就像 CAP 三角圖中指出的，MySQL 是一款知足 AC 但不知足 P 的分佈式系統。
試想一下，一個 MySQL 主從結構的數據庫集羣，當出現分區時，問題分區內的 Slave 會認爲主已經掛了，因此本身成爲本分區的 Master（腦裂）。
那麼如何才能讓分佈式系統具有分區容忍性呢？ 按照老慣例，咱們從」可用性分區容忍」和」一致性分區容忍」兩個方面來討論：
可用性分區容忍性保障機制： 可用性分區容忍的關鍵在於別讓一個事務一來全部節點來完成，這個很簡單，別要求全部節點共同同時參與某個事務便可。
一致性分區容忍性保障機制： 老實說，都產生分區了，哪還可能得到實時一致性。
換句話說，如何保障仍然只有一個腦呢？下面咱們來看下 PAXOS 算法是如何解決腦裂問題的。
Paxos 要求任何一個提議，至少有 (N/2)+1 的系統節點承認，才被認爲是可信的，這背後的一個基礎理論是少數服從多數。
想象一下，若是多數節點承認後，整個系統宕機了，重啓後，仍然能夠經過一次投票知道哪一個值是合法的（多數節點保留的那個值）。
這樣的設定也巧妙的解決了分區狀況下的共識問題，由於一旦產生分區，勢必最多隻有一個分區內的節點數量會大於等於 (N/2)+1。
經過這樣的設計就能夠巧妙的避開腦裂，固然 MySQL 集羣的腦裂問題也是能夠經過其餘方法來解決的，好比同時 Ping 一個公共的 IP，成功者繼續爲腦，顯然這就又製造了另一個單點。
這句話越是理解愈加以爲詭異，這會讓人覺得 PAXOS 逃離於 CAP 約束了，因此我的更願意理解爲：PAXOS 是惟一一種保障分佈式系統最終一致性的共識算法（所謂共識算法，就是你們都按照這個算法來操做，你們最後的結果必定相同）。
PAXOS 並無逃離 CAP 魔咒，畢竟達成共識是 (N/2)+1 的節點之間的事，剩下的 (N/2)-1 的節點上的數據仍是舊的，這時候仍然是不一致的。
如下摘自維基百科： 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 分析
上文提到過，單元化架構中的成千山萬的應用就像是計算器，自己無 CAP 限制，其 CAP 限制下沉到了其數據庫層，也就是螞蟻自研的分佈式數據庫 OceanBase（本節簡稱 OB）。
在 OB 體系中，每一個數據庫實例都具有讀寫能力，具體是讀是寫能夠動態配置（參考第二部分）。
實際狀況下大部分時候，對於某一類數據（固定用戶號段的數據）任意時刻只有一個單元會負責寫入某個節點，其餘節點要麼是實時庫間同步，要麼是異步數據同步。
OB 也採用了 PAXOS 共識協議。實時庫間同步的節點（包含本身）個數至少須要 (N/2)+1 個，這樣就能夠解決分區容忍性問題。
下面咱們舉個馬老師改英文名的例子來講明 OB 設計的精妙之處： 假設數據庫按照用戶 ID 分庫分表，馬老師的用戶 ID 對應的數據段在 [0-9]，開始由單元 A 負責數據寫入。
這時候發生了分區（好比 A 網絡斷開了），咱們將單元 A 對數據段 [0,9] 的寫入權限轉交給單元 B（更改映射），馬老師此次寫對了，爲 Jack Ma。
而在網絡斷開前請求已經進入了 A，寫權限轉交給單元 B 生效後，A 和 B 同時對 [0,9] 數據段進行寫入馬老師的英文名。
假如這時候都容許寫入的話就會出現不一致，A 單元說我看到馬老師設置了 Jason Ma，B 單元說我看到馬老師設置了 Jack Ma。
然而這種狀況不會發生的，A 提議說我建議把馬老師的英文名設置爲 Jason Ma 時，發現沒人迴應它。
一樣的，B 提出了將馬老師的英文名改爲 Jack Ma 後，大部分節點都響應了，因此 B 成功將 Jack Ma 寫入了馬老師的帳號記錄。
假如在寫權限轉交給單元 B 後 A 忽然恢復了，也不要緊，兩筆寫請求同時要求得到 (N/2)+1 個節點的事務鎖，經過 no-wait 設計，在 B 得到了鎖以後，其餘爭搶該鎖的事務都會由於失敗而回滾。
分區容忍性：OB 節點之間是有互相通訊的（須要相互同步數據），因此存在分區問題，OB 經過僅同步到部分節點來保證可用性。這一點就說明 OB 作了分區容錯。
可用性分區容忍性：OB 事務只須要同步到 （N/2)+1 個節點，容許其他的一小半節點分區（宕機、斷網等），只要 (N/2)+1 個節點活着就是可用的。
極端狀況下，好比 5 個節點分紅 3 份（2:2:1），那就確實不可用了，只是這種狀況機率比較低。
一致性分區容忍性：分區狀況下意味着部分節點失聯了，一致性顯然是不知足的。但經過共識算法能夠保證當下只有一個值是合法的，而且最終會經過節點間的同步達到最終一致性。
結語
我的感受本文涉及到的知識面確實很多，每一個點單獨展開均可以討論半天。回到咱們緊扣的主旨來看，雙十一海量支付背後技術上大快人心的設計究竟是啥？
基於用戶分庫分表的 RZone 設計。每一個用戶羣獨佔一個單元給整個系統的容量帶來了爆發式增加。
RZone 在網絡分區或災備切換時 OB 的防腦裂設計（PAXOS）。咱們知道 RZone 是單腦的（讀寫都在一個單元對應的庫），而網絡分區或者災備時熱切換過程當中可能會產生多個腦，OB 解決了腦裂狀況下的共識問題（PAXOS 算法）。
基於 CZone 的本地讀設計。這一點保證了很大一部分有着「寫讀時間差」現象的公共數據能被高速本地訪問。
剩下的那一丟丟不能本地訪問只能實時訪問 GZone 的公共配置數據，也興不起什麼風，做不了什麼浪。
好比用戶建立這種 TPS，不會高到哪裏去。再好比對於實時庫存數據，能夠經過「頁面展現查詢走應用層緩存」+「實際下單時再校驗」的方式減小其 GZone 調用量。
而這就是螞蟻 LDC 的 CRG 架構，相信 54.4 萬筆/秒還遠沒到 LDC 的上限，這個數字能夠作到更高。
固然雙 11 海量支付的成功不僅僅是這麼一套設計所決定的，還有預熱削峯等運營+技術的手段，以及成百上千的兄弟姐妹共同奮戰，特此在這向各位雙 11 留守同窗致敬。
感謝你們的閱讀，文中可能存在不足或遺漏之處，歡迎批評指正。
參考文獻：
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 半同步複製技術
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 億成交額背後的技術原理
https://www.cnblogs.com/antfin/articles/10299396.html
Backup
https://en.wikipedia.org/wiki/Backup
相關文章
- 1. 支付寶架構
- 2. 移動支付到底有多美？
- 3. 支付寶系統架構
- 4. 支付寶架構圖
- 5. 12306架構到底多牛X
- 6. 每秒100萬請求，「12306」的架構到底有多牛？
- 7. 螞蟻金服的技術架構，到底有多牛？
- 8. 支付寶支付-提現到我的支付寶
- 9. 天天都在用微信支付，你知道它的架構到底有多牛嗎？
- 10. 支付寶：批量付款到支付寶帳戶有密接口
- 更多相關文章...
- • Docker 架構 - Docker教程
- • SVN分支 - SVN 教程
- • 再有人問你分佈式事務，把這篇扔給他
- • IDEA下SpringBoot工程配置文件沒有提示
相關標籤/搜索
每日一句
-
每一个你不满意的现在，都有一个你没有努力的曾经。
歡迎關注本站公眾號,獲取更多信息
相關文章
- 1. 支付寶架構
- 2. 移動支付到底有多美？
- 3. 支付寶系統架構
- 4. 支付寶架構圖
- 5. 12306架構到底多牛X
- 6. 每秒100萬請求，「12306」的架構到底有多牛？
- 7. 螞蟻金服的技術架構，到底有多牛？
- 8. 支付寶支付-提現到我的支付寶
- 9. 天天都在用微信支付，你知道它的架構到底有多牛嗎？
- 10. 支付寶：批量付款到支付寶帳戶有密接口