Eureka、Zookeeper和Consul 的區別

主要區別的話，看CAP選擇，大部分註冊中心，就是在這個定理去選擇的，具體怎麼選擇，看下文

CAP定理：指的是在一個分佈式系統中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分區容錯性），三者不可同時得到。

一致性（C）：在分佈式系統中的全部數據備份，在同一時刻是否一樣的值。（全部節點在同一時間的數據徹底一致，越多節點，數據同步越耗時）

可用性（A）：負載過大後，集羣總體是否還能響應客戶端的讀寫請求。（服務一直可用，並且是正常響應時間）

分區容錯性（P）：分區容忍性，就是高可用性，一個節點崩了，並不影響其它的節點（100個節點，掛了幾個，不影響服務，越多機器越好）

再進一步解釋CAP理論： 就是說在分佈式存儲系統中，最多隻能實現上面的兩點。而因爲當前的網絡硬件確定會出現延遲丟包等問題，因此分區容忍性是咱們必須須要實現的。因此咱們只能在一致性和可用性之間進行權衡

C A 知足的狀況下，P不能知足的緣由：
數據同步(C)須要時間，也要正常的時間內響應(A)，那麼機器數量就要少，因此P就不知足

CP 知足的狀況下，A不能知足的緣由：
數據同步(C)須要時間, 機器數量也多(P)，可是同步數據須要時間，因此不能再正常時間內響應，因此A就不知足

AP 知足的狀況下，C不能知足的緣由：
機器數量也多(P)，正常的時間內響應(A)，那麼數據就不能及時同步到其餘節點，因此C不知足

使用場景 就是樓主的註冊中心選擇：
Zookeeper和Consul ：CP設計，保證了一致性，集羣搭建的時候，某個節點失效，則會進行選舉行的leader，或者半數以上節點不可用，則沒法提供服務，所以可用性無法知足

Eureka：AP原則，無主從節點，一個節點掛了，自動切換其餘節點可使用，去中心化

結論：分佈式系統中P,確定要知足，因此只能在CA中二選一
沒有最好的選擇，最好的選擇是根據業務場景來進行架構設計
若是要求一致性，則選擇zookeeper、Consul，如金融行業
若是要去可用性，則Eureka，如電商系統

 

--------------------------------------------------------------------------

 

最大的區別是Eureka保證AP, Consul爲CP。

 

Consul強一致性(C)帶來的是：

1. 服務註冊相比Eureka會稍慢一些。由於Consul的raft協議要求必須過半數的節點都寫入成功才認爲註冊成功
2. Leader掛掉時，從新選舉期間整個consul不可用。保證了強一致性但犧牲了可用性。

 

Eureka保證高可用(A)和最終一致性：

1. 服務註冊相對要快，由於不須要等註冊信息replicate到其餘節點，也不保證註冊信息是否replicate成功
2. 當數據出現不一致時，雖然A, B上的註冊信息不徹底相同，但每一個Eureka節點依然可以正常對外提供服務，這會出現查詢服務信息時若是請求A查不到，但請求B就能查到。如此保證了可用性但犧牲了一致性。

 

其餘方面，eureka就是個servlet程序，跑在servlet容器中; Consul則是go編寫而成。