隨著微服務和分佈式系統的廣泛運用，CAP 定理被大家熟悉起來，也成為了分佈式系統的三大指標。這篇文章我們就來聊一聊 CAP 定理。
CAP 定理
1998年，加州大學的計算機科學家 Eric Brewer 提出，分佈式系統有三個指標：
- Consistency.
- Availability.
- Partition Tolerance.
Eric Brewer 說，這三個指標不可能同時做到。然後就取首字母，組成了 CAP 定理。
一起來看看這三個指標分別代表什麼？
Consistency(一致性)：指讀寫數據的一致性，特指分佈式系統中數據的一致性。如何理解這句話？
假設我們現在有G1、G2 兩個實例，現在的值都是 v0，有一個客戶端向 G1 發起更新請求，將 v0 更新為 v1，如下圖所示：
在不做任何處理的情況下，G1實例對應的值為 v1，G2對應的值為v0。如果此時客戶端發起讀請求，讀 G1 實例上的數據是 v1，讀 G2 實例上的值是 v0，這就出現了數據不一致，這就不滿足數據一致性。如何保證數據一致性？需要在 G1 寫操作的時候，讓 G1 向 G2 發送一條消息，要求 G2 也改成 v1。
這樣的話，兩個實例的值都是 v1，不管客戶端讀取哪個服務器獲取的數據都一樣，這就是數據一致性。
用大白話來講就是多實例之間任何時刻數據都要相同。Availability（可用性）：指服務的高可用，特指分佈式系統中服務的高可用，這個就比較好理解，就是我給你發一個請求，你必須給我一個正確的響應。
Partition Tolerance（分區容錯性）：指在分佈式系統遇到網絡分區的情況下，仍然可以響應用戶的請求。怎麼理解呢？
在我們的分佈式系統中，節點組成的網絡本來應該是連通的。然而可能因為某些故障，使得有些節點之間不連通了，整個網絡就分成了幾塊區域，而數據就散佈在了這些不連通的區域中，這就叫分區。容錯的意思就是分區了也需要能夠正常訪問，大白話就是不要出現單點故障。在分佈式系統中，網絡抖動、故障是不可避免的所以 CAP 中，P 是必須實現的，只能在 CA 上做取捨。
接下來我們就來看看 CAP 的選擇策略及在開源中間件的運用，加深對 CAP 的理解。
保 CP 棄 A
對數據一致要求比較的場景，可以犧牲一定的可用性，來保證數據的一致性，也就是強一致性。比如金融行業，因為它任何時候都不允許出現數據不一致的情況，否則就會給用戶造成損失。因此，這種場景下必須保證 CP。
在我們的開源中間件中，ZooKeeper 就是採用保 CP 棄 A 策略，一起來看看。
在 ZooKeeper 集群中，Leader 節點之外的節點被稱為 Follower 節點，Leader 節點會專門負責處理用戶的寫請求：
- 當用戶向節點發送寫請求時，如果請求的節點剛好是 Leader，那就直接處理該請求；
- 如果請求的是 Follower 節點，那該節點會將請求轉給 Leader，然後 Leader 會先向所有的 Follower 發出一個 Proposal，等超過一半的節點同意後，Leader 才會提交這次寫操作，從而保證了數據的強一致性。
具體示意圖如下所示：
當出現網絡分區時，如果其中一個分區的節點數大於集群總節點數的一半，那麼這個分區可以再選出一個 Leader，仍然對用戶提供服務，但在選出 Leader 之前，不能正常為用戶提供服務；
如果形成的分區中，沒有一個分區的節點數大於集群總節點數的一半，那麼系統不能正常為用戶提供服務，必須待網絡恢復後，才能正常提供服務。
這種設計就是保證了數據的一致性，但是犧牲了一定的可用性，比如當 Leader 宕機的時候。
保 AP 棄 C
保 AP 棄 C 的策略是比較常見的策略，我們為了追求系統的高可用性，在出現網絡抖動的情況下，允許數據暫時不一致，犧牲一定的數據一致性。
網絡分區出現後，各個節點之間數據無法馬上同步，為了保證高可用，分佈式系統需要即刻響應用戶的請求。但是此時可能某些節點還沒有拿到最新數據，只能將本地舊的數據返回給用戶，從而導致數據不一致的情況。
比如我們的 eureka 註冊中心就是採用這種策略，在 eureka 集群中，當某個實例宕機了，並不會導致整個 eureka 註冊中心不可用，活躍的 eureka 服務器仍然可以響應外部請求。當宕機的服務器重新啟動後，在第一次數據同步之前，eureka 實例之間的數據是不一致的，但是經過一次數據同步之後，實例之間的數據就一致了，這就是通過犧牲數據的一致性，來保證系統的高可用。
以上就是 CAP 定理，希望對你的學習或者工作有所幫助。最後留一道思考題：
你們公司的分佈式架構是怎麼設計的？
