EureKa與ZooKeeper的CAP原則分析

回顧CAP原則

在關係型資料庫系統中RDBMS (Mysql、Oracle、sqlServer)，一個事務往往具有ACID特性

在非關係型資料庫中NoSQL(redis、mongdb)，往往遵循CAP原則

ACID是什麼？

• A(Atomicity) 原子性
  • 一個事務（transaction）中的所有操作，或者全部完成，或者全部不完成，不會結束在中間某個環節。事務在執行過程中發生錯誤，會被回滾（Rollback）到事務開始前的狀態，就像這個事務從來沒有執行過一樣。即，事務不可分割、不可約簡。
• C(Consistency)一致性
  • 在事務開始之前和事務結束以後，資料庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預設約束、觸發器、級聯回滾等。
• I(Isolation)隔離性
  • 資料庫允許多個併發事務同時對其資料進行讀寫和修改的能力，隔離性可以防止多個事務併發執行時由於交叉執行而導致資料的不一致。事務隔離分為不同級別，包括未提交讀（Read uncommitted）、提交讀（read committed）、可重複讀（repeatable read）和序列化（Serializable）
• D(Durability)永續性
  • 事務處理結束後，對資料的修改就是永久的，即便系統故障也不會丟失。

CAP是什麼？

• C(Consistency) 強一致性
  • 在分散式系統中的所有資料備份，在同一時刻是否同樣的值。（等同於所有節點訪問同一份最新的資料副本）
• A(Availability)可用性
  • 在叢集中一部分節點故障後，叢集整體是否還能響應客戶端的讀寫請求。（對資料更新具備高可用性）
• P(Partition tolerance) 分割槽容錯性
  • 以實際效果而言，分割槽相當於對通訊的時限要求。系統如果不能在時限內達成資料一致性，就意味著發生了分割槽的情況，必須就當前操作在C和A之間做出選擇。

CAP的三進二出：CA、AP、CP

CAP理論的核心

• 一個分散式系統不可能同時很好的滿足一致性，可用性，容錯性這三個需求
• 根據CAP原理，將NoSQL資料庫分成了滿足CA原則，滿足CP原則和滿足AP原則三大類：
  • CA:單點叢集，滿足一致性，可用性的系統，通常可擴充套件性較差
  • CP:滿足一致性，分割槽容錯性的系統，通常 效能不是特別高
  • AP:滿足可用性，分割槽容錯性的系統，通常可能對一致性要求要低一些

作為服務註冊中興，EureKa比ZooKeeper好在哪裡？

著名的CAP理論指出，一個分散式系統不可能同時滿足C(一致性)、A(可用性)、P(容錯性)。

由於分割槽容錯性P在分散式系統中是必須要保證，因此我們只能在A和C之間進行權衡。

• Zookeeper保證的是CP;
• Eureka保證的是AP;

Zookeeper保證的是CP

​ 當向註冊中心查詢服務列表時，我們可以容忍註冊中心返回的是幾分鐘以前的註冊資訊，但是不能接受 服務直接down掉不可用。也就是說，服務註冊功能對可用性的要求要高於一致性。但是ZK會出現這樣一種情況，當master結點因為網路故障與其他結點失去聯絡時，剩餘結點會重新進行leader選舉，問題在於，選取leader的時間太長30~120s,且選舉期間整個ZK叢集都是不可用的，這就導致在選舉期間註冊服務癱瘓。在雲部署的環境下，因為網路問題使得zk叢集失去master結點是較大概率會發生的事件，雖然最終能夠回覆，但是漫長的選舉時間導致的註冊長期不可用是不能容忍的。

Eureka保證的是AP

Eureka看明白了這一點，因此在設計時就優先保證可用性。Eureka各個結點都是平等的。幾個結點掛掉不會影響正常結點的工作，剩餘的結點依然可以提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊時，如果發現連線失敗，則會自動切換至其他結點，只要有一臺Eureka還在，就能保住註冊服務的可用性，只不過檢視到的資訊可能不是最新的，除此之外，Eureka還是一種自我保護機制，如果在15分鐘內超過85%的結點都沒有正常的心跳，那麼Eureka就認為客戶端與註冊中心出現了網路故障，此時會出現以下幾種情況：

​ 1.Eureka不再從註冊列表中移除因為長時間沒收到心跳而應該過期的服務

​ 2.Eureka仍然能夠接收新服務註冊和查詢請求，但是不會被同步到其他結點（即保證當前結點依然可用）

​ 3.當網路穩定時，當前網路穩定時，當前例項新的註冊資訊會被同步到其他結點中

因此，Eureka可用很好的應對因網路故障導致部分結點失去聯絡的情況，而不像Zookeeper那樣使整個註冊服務癱瘓