分佈式CAP理論：爲什麼CAP理論中的三個指標不能同時滿足呢？

前言

爲什麼CAP理論中的三個指標不能同時滿足呢？春暖花開、鳥語花香，莫要虛度這明媚的春天，一起學一學分佈式CAP理論吧~本文主要會對以下問題進行介紹：

• 分佈式系統有什麼特點？
• CAP理論的含義是什麼？
• 爲什麼CAP三者不能同時滿足？
• CAP理論怎麼應用？

（若文章有不正之處，或難以理解的地方，請多多諒解，歡迎指正）

分佈式系統的特點

對於分佈式系統最簡單的理解，就是一組計算機工作，但最終以一臺計算機的用戶身份顯示。簡單說，就是由多個不同業務的子系統，共同組成在用戶眼中就是一個系統的模式。但這些機器具有共享狀態，並不會因其中一個系統節點故障而影響整個系統。

分佈式系統技術是用來解決什麼問題的呢？

分佈式系統技術是用來解決集中式架構的性能瓶頸問題，其核心是可擴展性。舉個簡單的栗子：

假如有個大學生想做一個XX校園系統，這時他需要對於系統的數據存儲配置只有一個數據庫，也就是說，服務器與數據庫之間的交互是實時且一對一的：

然而這個XX校園系統在版本更新的路上披荊斬棘，從雞肋Demo系統升級到全省高校都在使用的校園系統，這時如果還將數據放在同一個數據庫或者數據表中，會在查詢過程中消耗過多的時間，使得響應時間過長，導致用戶體驗不良，所以進行了分庫操作：

假如依照用戶的名稱來進行分庫，服務器需要通過代理服務器選定訪問數據庫。在這裏，就需要兩個系統來進行向數據庫請求數據的操作。

所以，分佈式系統是通過對服務、存儲的擴展，來提高系統的處理能力。通過對多臺服務器協同工作，來完成單臺服務器無法處理的任務，如高併發或大數據量的任務。

因爲分佈式系統的複雜性，也可能會出現結點之間通信失敗，網絡分區失敗、數據不一致等問題。所以分佈式系統也可能出現對單點故障、無狀態的需要。

• 單點故障

  一般在系統中某個組件一旦失效，整個系統就無法工作了，爲了避免這種情況，往往會將單點故障作爲分佈式系統的設計目標之一，因爲單點故障，意味着單點不影響整體。

• 無狀態

  服務的無狀態，是爲了滿足部分機器宕機也不影響全部，可用於隨時進行擴展的需求。

那麼在設計分佈式系統時需要什麼理論作爲指導思想呢？這時，讓我們掌聲歡迎CAP理論出場！

CAP代表什麼含義

CAP分別是指一致性（Consistency）、可用性（Availablity）、分區容忍性（Partition Tolerance），一般分佈式系統只能滿足其三項中的兩項。

一致性（Consistency）

一致性是指“所有節點同時看到相同的數據”，也就是說在更新操作成功並返回到客戶端後，所有節點在同一時間的數據完全一致，所有節點所擁有的數據都是最新版本。

可用性（Availability）

可用性指的是“任何時候，讀寫都是成功的”，即服務一直可用，而且響應時間在正常範圍內。比如系統穩定性到了3個9、4個9，即99.9%、99.99%。

這裏的N個9對應的就是對可用性的一種描述，叫做SLA，即服務水平協議。

分區容錯性（Partition Tolerance）

分區容錯性是指“當部分結點出現消息丟失，或分區故障時，分佈式系統仍然能夠繼續運行”，即系統容忍網絡出現分區，且在遇到某個結點或網絡分區之間出現不可達的情況下，仍然能夠對外提供滿足一致性和可用性的服務。

在分佈式系統中，P的滿足是基本要素，一般是在CP或AP中進行選擇，實現更好的C或者提升A的性能。

那麼CAP理論中的一致性、可用性和分區容忍性不能同時滿足呢？

CAP理論的證明

爲什麼CAP不能同時滿足呢？

下面可以通過反證法來證明。

假如有一個實際場景，CAP三者都可以同時滿足。由於允許P的存在，則一定存在服務器（Server）之間的丟包，如此則不能保證C。

1. 在沒有分區的情況下，如果ClientA向Server1發送修改X=1的指令，在進行事務機制將Server1的X修改爲1後，Client1從Server1獲取到的X也會是1。因爲Client讀取到的值一定是最新值，所以這裏符合一致性，但顯然不具備分區容錯性，也就是說，如果服務器宕機了，那麼讀寫就一定會失敗。
   
2. 在有分區的情況下，如果ClientA向Server1和Server2發送修改X=1的指令，然而這指令並沒有成功發送給Server2，那麼Client1和Client從服務器中讀取到的X值就不一樣了。雖然這裏滿足了分區容錯性，但並不滿足一致性，而且如果爲了保證一致性，那麼在發送指令給服務器時，如果有一個命令沒有成功發送，所有服務器都不能接收這個請求，這無疑降低了可用性。
   
   所以這裏，可以對CAP的定義有更加明確的聲明：

• 一致性（Consistence）

  一致性被稱爲原子對象，任何的讀寫都應該看起來像是“原子”的，或串行的。

  寫入數據庫後讀取數據，一定能讀到前面寫的內容，所有的讀寫請求都像是全局排序依次進行。

• 可用性（Availability）

  對任何非失敗節點都應該在有限的時間內給出請求的迴應（請求的可中止性）。

• 分區容錯性（Partition Tolerance）

  允許節點之間丟失任意多的消息，當網絡分區發生時，節點之間的消息可能會完全丟失。

CAP理論的應用

1. 在架構設計中，不要把時間浪費在如何設計能滿足這三者的完美分佈式系統上，應當合理取捨。只能三者取其二。
2. 不同業務對於一致性的要求是不一樣的。像是微博點贊，用戶對不一致是不敏感的，能容忍相對長的一段時間數據不一致，只要做好交互，並不影響體驗；而電商商品價格的顯示是具有強一致性的，如果不能保證修改商品價格後的數據一致性，對交易是有很大影響的。
3. 在CAP理論中並沒有將網絡延遲需要花費的時間考慮進來，因爲只要是事務提交，節點間數據複製是一定要花時間的。

CP和AP架構的取捨

其實在實際工程中，可用性和一致性並不是完全對立的，我們往往關注的是如何在保持相對一致性的前提下，提高系統的可用性。

至於是使用CP或者AP架構，則取決於業務對一致性的要求。

CP架構：放棄可用性，追求一致性和分區容錯性

舉個栗子，ZooKeeper就是採用了CP一致性。

ZooKeeper是一個分佈式的服務框架，主要用來解決分佈式集羣中應用系統的協調和移置性問題。在ZooKeeper中，對應每一個事務操作請求，ZooKeeper都會爲其分配一個全局唯一的事務ID，每個事務ID對應一次更新操作，從這些事務ID中可以間接識別出ZooKeeper處理這些事務操作請求的全局順序。

AP架構：放棄強一致性，追求分區容錯性和可用性

舉個栗子，Eureka就採用了AP可用性。

Eureka是Spring Cloud微服務技術棧中的服務發現組件。

Eureka的各個節點都是平等的，幾個節點掛掉不影響正常節點的工作。剩餘節點依然可以提供註冊和查詢服務，只要有一臺Eureka在，就能保證註冊服務可用。只不過查看的信息可能不是最新版本，不保證一致性。

結語

本文主要是對CAP理論進行簡單介紹，文中的ZooKeeper和Eureka簡圖僅是爲了將CP和AP的應用區分出來，詳情可以自行查看其它博文。下一篇是關於BASE理論：分佈式BASE理論：數據一致性模型有哪些？

如果本文對你的學習有幫助，請給一個贊吧，這會是我最大的動力~

參考資料：

Spring Cloud之Eureka服務註冊與發現（概念原理篇）

5分鐘讓你瞭解 ZooKeeper 的功能和原理