2. 程式人生 > >分散式系統原理 之8 Paxos協議

分散式系統原理 之8 Paxos協議

阿新 • • 發佈：2019-02-07

分散式系統原理

Paxos協議

1. 簡介

Paxos 協議是少數在工程實踐中證實的強一致性、高可用的去中心化分散式協議。

Paxos 協議的流程較為複雜，但其基本思想卻不難理解，類似於人類社會的投票過程。Paxos 協議中，有一組完全對等的參與節點（稱為 accpetor），這組節點各自就某一事件做出決議，如果某個決議獲得了超過半數節點的同意則生效。Paxos 協議中只要有超過一半的節點正常，就可以工作，能很好對抗宕機、網路分化等異常情況。

2. 協議描述

2.1 節點角色

Paxos 協議中，有三類節點：

Proposer：提案者。Proposer 可以有多個，Proposer 提出議案（value）。所謂 value，在工程中可以是任何操作，例如“修改某個變數的值為某個值”、“設定當前 primary 為某個節點”等等。Paxos協議中統一將這些操作抽象為 value。不同的 Proposer 可以提出不同的甚至矛盾的 value，例如某個Proposer 提議“將變數 X 設定為 1”，另一個 Proposer 提議“將變數 X 設定為 2”，但對同一輪 Paxos過程，最多隻有一個 value 被批准。

Acceptor：批准者。Acceptor 有 N 個，Proposer 提出的 value 必須獲得超過半數(N/2+1)的 Acceptor批准後才能通過。Acceptor 之間完全對等獨立。

Learner：學習者。Learner 學習被批准的 value。所謂學習就是通過讀取各個 Proposer 對 value的選擇結果，如果某個 value 被超過半數 Proposer 通過，則 Learner 學習到了這個 value。回憶（2.4 ）不難理解，這裡類似 Quorum 機制，某個 value 需要獲得 W=N/2 + 1 的 Acceptor 批准，從而學習者需要至少讀取 N/2+1 個 Accpetor，至多讀取 N 個 Acceptor 的結果後，能學習到一個通過的 value。

上述三類角色只是邏輯上的劃分，實踐中一個節點可以同時充當這三類角色。

2.2 流程描述

Paxos 協議一輪一輪的進行，每輪都有一個編號。每輪 Paxos 協議可能會批准一個 value，也可能無法批准一個 value。如果某一輪 Paxos 協議批准了某個 value，則以後各輪 Paxos 只能批准這個value。++上述各輪協議流程組成了一個 Paxos 協議例項，即一次 Paxos 協議例項只能批准一個 value，這也是 Paxos 協議強一致性的重要體現。++

每輪 Paxos 協議分為階段，++準備階段和批准階段++，在這兩個階段 Proposer 和 Acceptor 有各自的處理流程。

流程 2.8.1：Proposer 的流程
（準備階段）
1. 向所有的 Acceptor 傳送訊息“Prepare(b)”；  這裡 b 是 Paxos的輪數，每輪遞增
2. 如果收到任何一個 Acceptor 傳送的訊息“Reject(B)”，則對於這個 Proposer 而言本輪 Paxos 失敗，將輪數 b 設定為 B+1 後重新步驟 1；

（批准階段，根據收到的 Acceptor 的訊息作出不同選擇）
3. 如果接收到的 Acceptor 的“Promise(b, v_i)”訊息達到 N/2+1 個（N 為 Acceptor 總數，除法取整，下同）；v_i 表示 Acceptor 最近一次在 i 輪批准過 value v。
    3.1 如果收到的“Promise(b, v)”訊息中，v 都為空，Proposer 選擇一個 value v，向所有 Acceptor廣播 Accept(b, v)；
    3.2 否則，在所有收到的“Promise(b, v _ i)”訊息中，選擇 i 最大的 value v，向所有 Acceptor 廣播訊息 Accept(b，v)；
4. 如果收到 Nack(B)，將輪數 b 設定為 B+1 後重新步驟 1；
流程 2.8.2：Accpetor 流程
（準備階段）
1. 接受某個 Propeser 的訊息 Prepare(b)。引數 B 是該 Acceptor 收到的最大 Paxos 輪數編號；V 是 Acceptor 批准的 value，可以為空
    1.1 如果 b>B，回覆 Promise(b, V_B)，設定 B=b;表示保證不再接受編號小於 b 的提案。
    1.2 否則，回覆 Reject(B)。

（批准階段）
2. 接收 Accept(b, v)，
    2.1 如果 b < B, 回覆 Nack(B)，暗示 proposer 有一個更大編號的提案被這個 Acceptor 接收了。
    2.2 否則設定 V=v。表示這個 Acceptor 批准的 Value 是 v。廣播 Accepted 訊息。

3. 例項

3.1 基本例子

基本例子裡有 5 個 Acceptor，1 個 Proposer，不存在任何網路、宕機異常。我們著重考察各個Accpetor 上變數 B 和變數 V 的變化，及 Proposer 上變數 b 的變化。

  1. 初始狀態

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 0 0 0 0 0
    V NULL NULL NULL NULL NULL
    - Proposer 1
    b 1

  2. Proposer 向所有 Accpetor 傳送“Prepare(1)”，所有 Acceptor 正確處理，並回復 Promise(1, NULL)

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 1 1 1 1 1
    V NULL NULL NULL NULL NULL
    - Proposer 1
    b 1

  3. Proposer 收到 5 個 Promise(1, NULL)，滿足多餘半數的 Promise 的 value 為空，此時傳送Accept(1, v1 )，其中 v1 是 Proposer 選擇的 Value。

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 1 1 1 1 1
    V v1 v1 v1 v1 v1

  4. 此時，v 1 被超過半數的 Acceptor 批准，v1 即是本次 Paxos 協議例項批准的 Value。如果 Learner學習 value，學到的只能是 v1

3.2 批准的 Value 無法改變

在同一個Paxos例項中，批准的Value是無法改變的，即使後續Proposer以更高的序號發起Paxos協議也無法改變 value。

  1. 例如，某次 Paxos 協議執行後，Acceptor 的狀態是：

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 3 3 3 2 2
    V v1 v1 v1 NULL NULL

    5 個 Acceptor 中，有 3 個已經在第三輪 Paxos 協議批准了 v 1 作為 value。其他兩個 Acceptor 的 V為空，這可能是因為 Proposer 與這兩個 Acceptor 的網路中斷或者這兩個 Acceptor 宕機造成的。

  2. 此時，即使有新的 Proposer 發起協議，也無法改變結果。假設 Proposer 傳送“prepare(4)消 息”，由於 4 大於所有的 Accpetor 的 B 值，所有收到 prepare 訊息的 Acceptor 回覆 promise 訊息。但 前三個 Acceptor 只能回覆 promise(4, v 1 _3)，後兩個 Acceptor 回覆 promise(4, NULL)。

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 4 4 4 4 4
    V v1 v1 v1 NULL NULL

  3. 此時，Proposer 可能收到若干個 Acceptor 傳送的 promise 訊息，沒有收到的 promise 訊息可能是網路異常造成的。無論如何，Proposer 要收到至少 3 個 Acceptor 的 promise 訊息後才滿足協議中大於半數的約束，才能傳送accpet訊息。這3個promise訊息中，至少有1個訊息是promise(4, v 1 _3)，至多 3 個訊息都是 promise(4，v 1 _3)。另一方面，Proposer 始終不可能收到 3 個 promise(4, NULL)訊息，最多收到 2 個。綜上，按協議流程，Proposer 傳送的 accept 訊息只能是“accept(4, v 1 )”而不能自由選擇 value。

    無論這個 accept 訊息是否被各個 Acceptor 接收到，都無法改變 v 1 是被批准的 value 這一事實。即從全域性看，有且只有 v 1 是滿足超過多數 Acceptor 批准的 value。例如，假設 accept(4, v 1 )訊息被Acceptor 1、Acceptor2、Acceptor4 收到，那麼狀態變為：

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 4 4 4 4 4
    V v1 v1 v1 v1 NULL

    從這個例子我們可以看到一旦一個 value 被批准，此後永遠只能批准這個 value。

3.3 一種不可能出現的狀態

Paxos 協議的核心就在與“批准的 value 無法改變”，這也是整個協議正確性的基礎，為了更好的理解後續對 Paxos 協議的證明。這裡再看一種看似可能，實際違反協議的狀態，這種狀態也是後續反證法證明協議時的一種錯誤狀態。

- Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
B 1 1 1 1 1
V v1 v1 v1 v2 v2

上述狀態中，3 個輪次為 1 的 Acceptor 的 value 為 v 1 ，2 個輪次更高的 Acceptor 的 value 為 v 1 。此時被批准的 value 是 v 1 。

假設此時發生新的一輪 b=3 的 Paxos 過程，Proposer 有可能收到 Acceptor 3、4、5 發出的 3 個promise 訊息分別為“promise(1, v 1 _1)”,“promise(2, v 2 _2)” “promise(2, v 2 _2)”。按協議，proposer選擇 value 編號最大的 promise 訊息，即 v 2 _2 的 promise 訊息，傳送訊息“Accept(3, v 2 )”，從而使得最終的批准的 value 成為 v 2 。就使得批准的 value 從 v 1 變成了 v 2 。

上述假設看似正確，其實不可能發生。這是因為本節中給出的初始狀態就是不可能出現的。這是因為，要到達成上述狀態，發起 prepare(2)訊息的 proposer 一定成功的向 Acceptor 4、Acceptor 5傳送了 accept(2, v 2 )。但傳送 accept(2, v 2 )的前提只能是 proposer 收到了 3 個“promise(2, NULL)”訊息。 然而，從狀態我們知道，在 b=1 的那輪 Paxos 協議裡，已經有 3 個 Acceptor 批准了 v 1 ,這 3 個Acceptor 在 b=2 時發出的訊息只能是 promise(2，v 1_ 1)，從而造成 proposer 不可能收到 3 個“promise(2,NULL)”，至多隻能收到 2 個“promise(2, NULL)”。另外，只要 proposer 收到一個“promise(2，v 1 _1)”，其傳送的 accept 訊息只能是 accept(2, v 1 )。

從這個例子我們看到 Prepare 流程中的第 3 步是協議中最為關鍵的一步，它的存在嚴格約束了“批准的 value 無法改變”這一事實。在後續協議推導中我們將看到這一步是如何被設計出來的。

3.4 節點異常

這裡給一個較為複雜的異常狀態下Paxos 執行例項。本例子中有 5 個Acceptor和 2 個 Proposer。

  1. Proposer 1 發起第一輪 Paxos 協議，然而由於異常，只有 2 個 Acceptor 收到了 prepare(1)訊息。

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 1 1 0 0 0
    V NULL NULL NULL NULL NULL

  2. Proposer 1 只收到 2 個 promise 訊息，無法發起 accept 訊息；此時，Proposer 2 發起第二輪 Paxos協議，由於異常，只有 Acceptor 1、3、4 處理了 prepare 訊息，併發送 promise(2, NULL)訊息

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 2 1 2 2 0
    V NULL NULL NULL NULL NULL

  3. Proposer 2 收到了 Acceptor 1、3、4 的 promise(2, NULL) 訊息，滿足協議超過半數的要求，選擇了 value 為 v 1 ,廣播了 accept(2, v 1 )的訊息。由於異常，只有 Accptor 3、4 處理了這個訊息。

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 2 1 2 2 0
    V NULL NULL v1 v1 NULL

  4. Proposer 1 以b=3發起新一輪的Paxos協議，由於異常，只有Acceptor 1、2、3、5處理了prepare(3)訊息。

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 3 3 3 2 3
    V NULL NULL v1 v1 NULL

  5. 由於異常，Proposer 1 只收到 Acceptor1、2、5 的 promise(3, NULL)的訊息，符合協議要求，Proposer 1 選擇 value 為 v 2 ，廣播 accept(3, v 2 )訊息。由於異常，這個訊息只被 Acceptor 1、2 處理。

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 3 3 3 2 3
    V v2 v2 v1 v1 NULL

    當目前為止，沒有任何value被超過半數的Acceptor批准，所以Paxos協議尚沒有批准任何value。然而由於沒有 3 個 NULL 的 Acceptor，此時能被批准的 value 只能是 v 1 或者 v 2 其中之一。

  6. 此時 Proposer 1 以 b=4 發起新的一輪 Paxos 協議，所有的 Acceptor 都處理了 prepare(4)訊息。

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 4 4 4 4 4
    V v2 v2 v1 v1 NULL

  7. 由於異常，Proposer 1 只收到了 Acceptor3 的 promise(4, v 1 _3)訊息、Acceptor4 的 promise(4,v 1 _2)、Acceptor5 的 promise(4, NULL)訊息，按協議要求，只能廣播 accept(4, v 1 )訊息。假設 Acceptor2、3、4 收到了 accept(4, v 1 )訊息。由於批准 v 1 的 Acceptor 超過半數，最終批准的 value 為 v 1 。

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 4 4 4 4 4
    V v2 v1 v1 v1 NULL

4. 競爭及活鎖

從前面的例子不難看出，Paxos 協議的過程類似於“佔坑”，哪個 value 把超過半數的“坑”（Acceptor）佔住了，哪個 value 就得到批准了。

這個過程也類似於單機系統並行系統的加鎖過程。假如有這麼單機系統：系統內有 5 個鎖，有多個執行緒執行，每個執行緒需要獲得 5 個鎖中的任意 3 個才能執行後續操作，操作完成後釋放佔用的鎖。我們知道，上述單機系統中一定會發生“死鎖”。例如，3 個執行緒併發，第一個執行緒獲得 2 個鎖，第二個執行緒獲得 2 個鎖，第三個執行緒獲得 1 個鎖。此時任何一個執行緒都無法獲得 3 個鎖，也不會主動釋放自己佔用的鎖，從而造成系統死鎖。

但在 Paxos 協議過程中，雖然也存在著併發競爭，不會出現上述死鎖。這是因為，Paxos 協議引入了輪數的概念，高輪數的 paxos 提案可以搶佔低輪數的 paxos 提案。從而避免了死鎖的發生。然而這種設計卻引入了“活鎖”的可能，即 Proposer 相互不斷以更高的輪數提出議案，使得每輪 Paxos過程都無法最終完成，從而無法批准任何一個 value。

  1. Proposer 1 以 b=1 提起議案，傳送 prepare(1)訊息，各 Acceptor 都正確處理,迴應 promise(1,NULL)

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 1 1 1 1 1
    V NULL NULL NULL NULL NULL

  2. Proposer 2 以 b=2 提起議案，傳送 prepare(2)訊息，各 Acceptor 都正確處理,迴應 promise(2,NULL)

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 2 2 2 2 2
    V NULL NULL NULL NULL NULL

  3. Proposer 1 收到 5 個 promise(1, NULL)訊息，選擇 value 為 v 1 傳送 accept(1, v 1 )訊息，然而這個訊息被所有的 Acceptor 拒絕，收到 5 個 Nack(2)訊息。

  4. Proposer 1 以 b=3 提起議案，傳送 prepare(3)訊息，各 Acceptor 都正確處理,迴應 promise(3,NULL)

    - Acceptor 1 Acceptor 2 Acceptor 3 Acceptor 4 Acceptor 5
    B 3 3 3 3 3
    V NULL NULL NULL NULL NULL

  5. Proposer 2 收到 5 個 promise(2, NULL)訊息，選擇 value 為 v 2 傳送 accept(2, v 2 )訊息，然而這個訊息被所有的 Acceptor 拒絕，收到 5 個 Nack(3)訊息。

上述過程交替進行，則永遠無法批准一個 value，從而形成 Paxos 協議活鎖。Paxos 協議活鎖問題也是這個協議的主要問題。

參考：《分散式系統原理介紹》 - 劉傑

相關推薦

分散式系統原理 之8 Paxos協議

分散式系統原理 Paxos協議 1. 簡介 Paxos 協議是少數在工程實踐中證實的強一致性、高可用的去中心化分散式協議。 Paxos 協議的流程較為複雜，但其基本思想卻不難理解，類似於人類社會的投票過程。Paxos 協議中，有一組完全對等的參與節點

分散式系統原理（8）基於 MVCC 的分散式事務

基於 MVCC 的分散式事務 實現分散式事務除了使用類似“兩階段提交”協議等方式外，另一種簡單高效的方式就是使用MVCC(Multi-version Cocurrent Control，多版本併發控制)技術。MVCC 技術最初也是在資料庫系統中被提出，但這種思想並不侷限於單機的分散式

分散式系統原理之cap理論

1.1 CAP理論的含義   Cap理論表示在分散式系統中一致性(C)、可用性(A)和分割槽容錯性(P)最多隻能同時滿足兩個。  一致性:客戶端更新資料成功後,在任意時刻,在系統任意對外提供服務的節點,讀取到的資料都是最新寫入的資料。(強一致性)。  可用性:當系統出現異常時，

分散式系統原理（9）Paxos 協議

Paxos 協議 簡介 Paxos 協議是少數在工程實踐中證實的強一致性、高可用的去中心化分散式協議 Paxos 協議的流程較為複雜，但其基本思想卻不難理解，類似於人類社會的投票過程。Paxos 協議中，有一組完全對等的參與節點（稱為 accpetor），這組節點各自就某一事

分散式系統原理（7）兩階段提交協議

兩階段提交協議 問題背景 兩階段提交（two phase commit）協議是一種歷史悠久的分散式控制協議。最早用於在分散式資料庫中，實現分散式事務。這裡有必要首先簡單介紹一下兩階段提交的最初問題背景，從而能更好的理解該協議 在經典的分散式資料庫模型中，同一個資料庫的各個副本

操作系統原理之進程和線程學習

訪問 發生 執行 等待 保護 輸出 內存 不存在 當前 進程 操作系統必須交替執行多個進程，在合理的響應時間範圍內使處理器的利用率達到最大。 操作系統按照程序分配的優先級給進程分配資源，避免死鎖。 操作系統支持進程間的通信和用戶創建進程 定義：正在計算機上執行的程

分散式系統理解之CAP理論的發展

最近一段時間在研究Zookeeper，深入瞭解了下分散式系統的發展以及CAP理論的發展，因此寫下這篇文章總結一下，由於博主水平有限，如有不足之處可以留言討論，本文查閱了很多資料，如有侵權請聯絡博主刪除。 傳統IT系統的要求 效能 在效能上要求快速響應，支援更

分散式系統原理（10）CAP 理論

CAP 理論 CAP 理論是由 Eric Brewer 提出的分散式系統中最為重要的理論之一。本文將 CAP 理論安排在原理部分的最後介紹是為了利用前面已經介紹過的幾種分散式協議來幫助理解 CAP 理論 定義 CAP 理論的定義很簡單，CAP 三個字母分別代表了分散式系統中三

分散式系統原理（6）日誌技術

日誌技術 日誌技術是宕機恢復的主要技術之一。日誌技術最初使用在資料庫系統中。嚴格來說日誌技術不是一種分散式系統的技術，但在分散式系統的實踐中，卻廣泛使用了日誌技術做宕機恢復，甚至如 BigTable 等系統將日誌儲存到一個分散式系統中進一步增強了系統容錯能力 本章首先簡單介紹資料

分散式系統原理（5）Quorum 機制

分散式系統原理（5）Quorum 機制 Quorum 機制是一種簡單有效的副本管理機制。本節首先討論一種最簡單的副本控制規則 write-all-read-one，在此基礎上，放鬆約束，討論 quorum 機制 約定 為了簡化討論，本節先做這樣的約定：更新操作（write）是

《分散式系統原理與範型》第二版筆記

書籍的獲取渠道： 1、購買；2、search in the net。 第一章 1、分散式系統定義 分散式系統是若干獨立計算機的集合，這些計算機對於使用者來說就好像是單個相關係統。   a:機器本身是獨立的，b：對於使用者來說就像是與單個系統打交道。（缺一不可）  特性：1、

分散式爬蟲原理之分散式爬蟲原理

我們在前面已經實現了Scrapy微博爬蟲，雖然爬蟲是非同步加多執行緒的，但是我們只能在一臺主機上執行，所以爬取效率還是有限的，分散式爬蟲則是將多臺主機組合起來，共同完成一個爬取任務，這將大大提高爬取的效率。一、分散式爬蟲架構在瞭解分散式爬蟲架構之前，首先回顧一下Scrapy的

分散式系統理論之Quorum機制

一，Quorum機制介紹 在分散式系統中有個CAP理論，對於P（分割槽容忍性）而言，是實際存在 從而無法避免的。因為，分佈系統中的處理不是在本機，而是網路中的許多機器相互通訊，故網路分割槽、網路通訊故障問題無法避免。因此，只能儘量地在C 和 A 之間尋求平衡。對於資料儲存而言，為了提高可用性（Availab

大資料分散式系統原理概述

一、分散式系統的理論 1、CAP原理   CAP原理指的是，一致性(Consistency)、可用性(Availability)、分割槽容忍性(Partition tolerance)這三個要素最多隻能同時實現兩點，不可能三者兼顧。因此在進行分散式架構設計時，必須做出取捨。

分散式系統 （大規模分散式系統原理解析和架構實踐）

分散式系統的基礎理論： 分散式系統：多臺機器通過網路連線在一起，作為一個整體為上層提供服務。 一、基礎理論知識：資料分佈、複製、一致性、容錯。 1、異常 （1）伺服器宕機（記憶體錯誤，伺服器停電）：如

分布式系統原理之cap理論

系統 引導 1.3 更新數據 節點 業界 文獻 使用 開啟 1.1 CAP理論的含義 Cap理論表示在分布式系統中一致性(C)、可用性(A)和分區容錯性(P)最多只能同時滿足兩個。 一致性:客戶端更新數據成功後,在任意時刻,在系統任意對外提供服務的節點,讀取到的數據

資料庫系統原理之SQL(三)

資料庫系統原理之SQL(三) 1. SQL的組成 1. 資料查詢 2. 資料定義 3. 資料操作 4. 資料控制 2. 資料定義語言 CREATE建立資料庫或資料庫物件 建立資料庫 ~~~ CREATE {DATABASE | SCHEMA} [IF NOT EXISTS] db_name [DEFAU

分散式系統架構之構建你的任務排程中心

**分散式系統架構之構建你的任務排程中心** 分散式系統中，我們經常會遇到定時執行任務，而這些定時任務中，多數情況都是需要執行一些http請求。 比如： - 輪訓支付結果（雖然第三方支付中心有支付回撥，但有時候並不能有效保證你的業務系統能收到正確的結果） - 未支付訂單超時取消，電商系統訂單，使用者未支付

從Paxos到Zookeeper分散式一致性原理與實踐 讀書筆記之（一） 分散式架構

1.1 從集中式到分散式  1 集中式特點  結構簡單，無需考慮對多個節點的部署和節點之間的協作。  2  分散式特點 分不性：在時間可空間上隨意分佈，機器的分佈情況隨時變動 對等性：計算機之間沒有主從之分，所有計算機之間是對等的。副本是分散式系統對資料

《從 PAXOS 到 ZOOKEEPER：分散式一致性原理與實踐》讀書筆記[1]——一致性協議

1 分散式 1.1 定義 分散式系統是一個硬體或軟體元件分佈在不同的網路計算機上，彼此之間僅僅通過訊息傳遞進行通訊和協調的系統 1.2 特點 分佈性、對等性、併發性、缺乏全域性時鐘、故障總是會發生 2 CAP 和 BASE 2.1 CAP CAP 理論：一個分散式系統不可