CAP定理，Eureka的工作原理以及它與ZooKeeper的差別

CAP定理

在一個分布式系統中，Consistency(一緻性)，Availability(可用性)，Partition tolerance(分區容錯性)，三者不可兼得。

一緻性(“C”) : 在分布式系統中的所有資料備份，在同一時刻是否有相同的值。(所有的節點在同一時間的資料完全一緻，節點數量越多，同步消耗的時間也就越多)

可用性(“A”): 叢集負載過大，叢集整體是否能相應用戶端的讀寫要求。(服務一直可用，而且是正常的相應時間)

分區容錯性(“P”): 分區容錯性就是高可用性，當一個或者多個節點崩潰，并不會影響其他節點。(1000個節點，崩潰了幾個節點，并不會影響服務，機器越多越好)

CAP理論就是說，在一個分布式存儲系統中，最多隻能實作上面的兩點。而且由于目前的網絡硬體肯定會出現延遲和丢包的問題，是以分區容錯性我們是必須要實作的，是以我們隻能在一緻性和可用性之間進行權衡。

ps: 在分布式的系統中，P是要必須滿足，是以隻能在CA之間選擇

沒有最好的選擇，最好的選擇是根據業務場景來進行架構設計

如果選擇一緻性，則選擇zookeeper，例如金融行業

如果要求可用性，則選擇Eureka，例如電商系統

Eureka和zookeeper的差別

Eureka的工作原理

Eureka包含兩個元件，分别是Eureka server和Eureka client，為了友善解釋，下面統稱為server和client，client是一個Java用戶端，用于簡化和server的互動。

1. server提供服務發現的能力，服務啟動時，會向server注冊自己的資訊。
2. 微服務啟動後，會周期性地向Eureka Server發送心跳（預設周期為30秒）以續約自己的資訊。如果server在一定時間内沒有接收到某個微服務節點的心跳，server将會登出該微服務節點（預設90秒)。但是在正式生産環境中，網絡通信會面臨各種問題，比如微服務狀态正常，但是由于網絡分區故障時，server的登出服務執行個體會讓大部分微服務不可用，是以可以通過自我保護機制。(自我保護機制：當節點進入自我保護機制，不在登出任何的微服務，當網絡故障恢複後，節點自動退出自我保護機制。可以通過配置eureka.server.enable-self-preservation=true開啟自我保護機制)
3. .每個server同時也是client，多個server之間通過複制的方式完成服務系統資料庫的同步；
4. client會緩存server中的資訊。即使所有的server節點都宕掉，服務消費者依然可以使用緩存中的資訊找到服務提供者。

主要差別

1. Zookeeper保證CP

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

2. Eureka保證AP

   Eureka看明白了這一點，是以在設計時就優先保證可用性。Eureka各個節點都是平等的，幾個節點挂掉不會影響正常節點的工作，剩餘的節點依然可以提供注冊和查詢服務。而Eureka的用戶端在向某個Eureka注冊或時如果發現連接配接失敗，則會自動切換至其它節點，隻要有一台Eureka還在，就能保證注冊服務可用(保證可用性)，隻不過查到的資訊可能不是最新的(不保證強一緻性)。除此之外，Eureka還有一種自我保護機制，如果在15分鐘内超過85%的節點都沒有正常的心跳，那麼Eureka就認為用戶端與注冊中心出現了網絡故障，此時會出現以下幾種情況：

Eureka不再從注冊清單中移除因為長時間沒收到心跳而應該過期的服務

Eureka仍然能夠接受新服務的注冊和查詢請求，但是不會被同步到其它節點上(即保證目前節點依然可用)

當網絡穩定時，目前執行個體新的注冊資訊會被同步到其它節點中

是以， Eureka可以很好的應對因網絡故障導緻部分節點失去聯系的情況，而不會像zookeeper那樣使整個注冊服務癱瘓。

新手寫部落格，組織能力不是很好，本文主要借鑒：

借鑒1

借鑒2