微服務架構中的CAP原理是什么

本篇文章給大家分享的是有關微服務架構中的CAP原理是什么，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

什么是分布式 CAP 原理，什么是分區(qū)容錯性，zookeeper 和 eureka 的 CAP 區(qū)別是什么，還有作為公司的架構師你們是怎么做的，那些分布式系統(tǒng)設計成了 CP、AP，為什么這樣設計等等一系列問題。

分布式系統(tǒng) CAP 到底指什么

• C（Consistency）：一致性，即數據一致性，特指分布式系統(tǒng)中的數據一致性。

• A（Availability）：可用性，即服務的高可用，特指分布式系統(tǒng)中服務的高可用，某個服務癱瘓不影響整個分布式系統(tǒng)的正常運行。

• P（Partition Tolerance）：分區(qū)容錯性（也有的叫分區(qū)耐受性），即網絡故障，特指分布式系統(tǒng)中服務之間出現(xiàn)了網絡故障，整個分布式系統(tǒng)仍然保持可用性和一致性。

  
  

一句話概括 CAP：在分布式系統(tǒng)中，網絡故障，服務癱瘓，整個系統(tǒng)的數據仍然保持一致性。

上面的表述可能不容易理解，舉一個通俗的例子講講什么是分布式 CAP 原理。

大白話描述案例：

如上圖所示，小張在京東商城準備購買幾本微服務實戰(zhàn)相關的書籍，訂單總金額共 200 元，他剛好有一張滿 200 減 100 元的優(yōu)惠劵。 

這時分 3 種情況說明分布式系統(tǒng)的 CAP 如下：

1. 數據一致性體現(xiàn)：

• 使用 100 元優(yōu)惠劵扣減，實付 100 元，優(yōu)惠劵用完。

• 使用 100 元優(yōu)惠劵失敗，實付 200 元，優(yōu)惠劵還在。

2. 系統(tǒng)可用性體現(xiàn)：

• 小張下訂單時，訂單服務或是 PLUS 會員服務掛了，此時不應該影響小張下單。

3. 系統(tǒng)分區(qū)容錯性體現(xiàn)：

• 小張下訂單時，訂單服務和 PLUS 會員服務之間網絡不通也不能影響小張下單。

什么是分區(qū)容錯性

CAP 定理中最難理解的概念是 P，分區(qū)容錯性，畫個圖大家就理解了。

在斷網的情況下，2 臺服務器變成了獨立網絡，彼此無法通信，這個情況就是分區(qū)。在分區(qū)的情況下，分布式系統(tǒng)如果要保證數據一致性和可用性的話，那就滿足分區(qū)容錯性了。

CAP 技術實現(xiàn)的難度，下面一一解惑

目前大部分互聯(lián)網企業(yè)都是微服務架構，即分布式系統(tǒng)。 
現(xiàn)在某電商微服務架構，假設出現(xiàn)網絡故障（P），服務掛掉（A），整個系統(tǒng)的數據仍然保持一致。這是無法做到的。

相對可以實現(xiàn)的方案： 
業(yè)界的做法是 CAP 三選其二，即

• CP

• AP

• CA（請思考？后面敘述）

  
  

當服務之間出現(xiàn)網絡故障的情況下：

問題：

1. 如何保證訂單服務和 PLUS 會員服務高可用？

2. 下訂單同時扣除 100 元優(yōu)惠劵如何實現(xiàn)？

   
   

分布式系統(tǒng)的解決方案：

1. CAP 犧牲一致性（AP）：保證高可用，即保證訂單服務可以正常訪問，保證 PLUS 會員服務可以正常訪問，犧牲了數據的一致性。

   小張去京東商城下訂單（但是沒有扣除 100 元優(yōu)惠劵），這種情況下，小張訂單提交成功后，再去查看 100 元優(yōu)惠劵還在，居然沒有扣除成功，但是實付金額是 100 元，很納悶（心里竊喜）。

• 怎么辦呢？如何解決這種問題？ 
  一般的做法是，當網絡恢復正常的情況下，訂單服務重試請求 PLUS 會員服務，再扣除 100 元優(yōu)惠劵。

  
  

2. CAP 犧牲可用性（CP）：保證數據一致性。

   當小張去京東商城下單時，提示：“網絡異常，請稍后再試”。

• 怎么辦呢？如何解決這種問題？ 
  只能等網絡恢復正常后，小張才可以成功下單。

  
  

3. CAP 犧牲分區(qū)容錯性（CA）：不要P分區(qū)，即不允許出現(xiàn)網絡故障，這是不可能實現(xiàn)的。 
   所以在分布式系統(tǒng)中，是不存在 CA 的。即使傳統(tǒng)單體系統(tǒng)也做不到CA，因為單體系統(tǒng)也會出現(xiàn)單一故障。

   
   

通過小張在京東商城下訂單的案例，小伙伴應該都弄明白了吧。

下面分析兩個微服務架構中常用的服務注冊中心 —— zookeeper & eureka 的 CAP 原理

1）圖解 zookeeper 的 CAP 原理 
注：此處不介紹 zookeeper 底層原理和實現(xiàn) 
zookeeper 作為微服務注冊中心是 CP 原理，即保證了數據的一致性，犧牲了可用性。如下圖所示：

• zookeeper 的數據同步原理： 
  Client1 客戶端向 zk Server1 注冊，zk Server1 同步信息給 zk Server2，zk Server2 是注冊中心的 leader 節(jié)點，該節(jié)點負責把消息廣播同步給其他 follower 的 zk 節(jié)點，為了保證數據的一致性，只有等整個注冊中心信息同步完成，Client1客戶端才能收到注冊成功的消息。

• 如上圖所示，當注冊中心 leader 重啟或是出現(xiàn)網絡故障的情況下，整個 zk 集群重新選舉 leader 節(jié)點，在選舉期間，Client 客戶端無法注冊，即此時 zookeeper 服務不可用，所以犧牲了系統(tǒng)的可用性。

• 如上圖所示，只有等到整個系統(tǒng)選舉出 leader 節(jié)點，系統(tǒng)才能恢復注冊，故 zookeeper 為了保證數據一致性，犧牲了系統(tǒng)的可用性。

• CP 有一個致命的缺點，就是在大型分布式系統(tǒng)中，網絡非常復雜，leader 節(jié)點出現(xiàn)故障的頻率特別高，而且很容易引起雪崩。所以這是很多大型分布式系統(tǒng)都不選擇 zookeeper 作為注冊中心的原因。

  
  

2）圖解 Eureka 的 CAP 原理 
如下圖所示：

• eureka 是 AP 原理，即保證了系統(tǒng)的可用性，卻犧牲了系統(tǒng)的一致性。

• eureka 的數據同步原理： 
  第一步，Client1 客戶端注冊到 eureka Server1 服務中； 
  第二步，eureka Server1 直接告訴 Client1 注冊成功。 
  第三步，eureka Server1 把 Client1 的注冊信息同步給 Server2，為了保證服務的可用性，eureka Server 之間是異步同步的。

通過以上的案例描述和圖形解讀，相信大家對于微服務（分布式系統(tǒng)）架構中 CAP 原理有了一定的了解。比如知道了什么是 CAP 原理，什么是分區(qū)容錯性，zookeeper 和 eureka 作為注冊中心的 CAP 區(qū)別是什么。同時希望對今后你們公司的系統(tǒng)架構設計有所幫助，系統(tǒng)設計是遵循 CP 還是 AP。

以上就是微服務架構中的CAP原理是什么，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業(yè)資訊頻道。