文章目錄

• • • 前言
  • 分布式系統的特點
  • • • 分布式系統技術是用來解決什么問題的呢？
  • CAP代表什么含義
  • • 一致性（Consistency）
    • 可用性（Availability）
    • 分區容錯性（Partition Tolerance）
  • CAP理論的證明
  • CAP理論的應用
  • • CP和AP架構的取舍
    • • CP架構：放棄可用性，追求一致性和分區容錯性
      • AP架構：放棄強一致性，追求分區容錯性和可用性
    • 結語

前言

為什么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。

在沒有分區的情況下，如果ClientA向Server1發送修改X=1的指令，在進行事務機制將Server1的X修改為1后，Client1從Server1獲取到的X也會是1。因為Client讀取到的值一定是最新值，所以這里符合一致性，但顯然不具備分區容錯性，也就是說，如果服務器宕機了，那么讀寫就一定會失敗。

在有分區的情況下，如果ClientA向Server1和Server2發送修改X=1的指令，然而這指令并沒有成功發送給Server2，那么Client1和Client從服務器中讀取到的X值就不一樣了。雖然這里滿足了分區容錯性，但并不滿足一致性，而且如果為了保證一致性，那么在發送指令給服務器時，如果有一個命令沒有成功發送，所有服務器都不能接收這個請求，這無疑降低了可用性。

所以這里，可以對CAP的定義有更加明確的聲明：

• 一致性（Consistence）

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

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

• 可用性（Availability）

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

• 分區容錯性（Partition Tolerance）

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

CAP理論的應用

在架構設計中，不要把時間浪費在如何設計能滿足這三者的完美分布式系統上，應當合理取舍。只能三者取其二。

不同業務對于一致性的要求是不一樣的。像是微博點贊，用戶對不一致是不敏感的，能容忍相對長的一段時間數據不一致，只要做好交互，并不影響體驗；而電商商品價格的顯示是具有強一致性的，如果不能保證修改商品價格后的數據一致性，對交易是有很大影響的。

在CAP理論中并沒有將網絡延遲需要花費的時間考慮進來，因為只要是事務提交，節點間數據復制是一定要花時間的。

CP和AP架構的取舍

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

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

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

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

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

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

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

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

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

總結

以上是生活随笔為你收集整理的分布式CAP理论：为什么CAP理论中的三个指标不能同时满足呢？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。