SpringCloud_Eureka與Zookeeper對比

關係型數據庫與非關係型數據庫及其特性：

RDBMS(Relational Database Management System 關係型數據庫) ：mysql/oracle/sqlServer等   ========》ACID特性

NOSQL(Not Only SQL 非關係型數據庫)：redis/mongdb等  ========》 CAP特性

ACID：A(Atomicity)原子性、C(Consistency)一致性、I(Isolation)獨立性、D(Durability)持久性

CAP：C(Consistency)強一致性、A(Availability)可用性、P(Partition tolerance)分區容錯性

CAP三進二原則：

在任何一個分佈式系統中都沒法同時知足CAP，只能三個裏面選擇兩個

CAP介紹及其對應產品：

 

 

NoSQL

CA：單點集羣，知足一致性，可用性的系統，一般在擴展性上不太強大（產品：RDBMS）

CP：知足一致性，分區容忍性的系統，一般性能不是特別高（產品：MongoDB/HBase/Redis）

AP：知足可用性，分區容忍性的系統，一般可能對一致性要求更低一些（產品：CouchDB/Cassandra/DvnamoDB）

CAP理論就是說在分佈式系統中，最多隻能實現上面兩點；而因爲當前的網絡硬件確定會出現延遲丟包問題，因此分區容忍必需要實現。因此分佈式系統只能在一致性和可用性之間進行權衡，沒有NoSQL系統能同時保證CAP三點。

Zookeeper保證的是CP，Eureka保證的是AP：

Zookeeper保證CP：在集羣中，當master節點由於網絡故障與其餘節點失去聯繫時，剩餘節點會從新進行leader選舉，選舉leader的時間太長，30~120秒，且選舉期間整個zk集羣都是不可用的，這就致使在選舉期間註冊服務癱瘓，而在雲部署的環境下，因網絡問題使得zk集羣失去master節點是較大機率發生的事，雖然服務最終可以恢復，可是長時間選舉時間致使的註冊長期不可用是不能容忍的。

Eureka保證的是AP：Eureka各個節點都是平等的，幾個節點掛掉不會影響正常節點的工做，剩餘的節點依然能夠提供註冊和查詢服務。而Eureka的客戶端在向某個Eureka註冊時若是發現鏈接失敗，則會自動切換至其它節點，只要有一臺Eureka還在，就能保證註冊服務可用(保證可用性)，只不過查到的信息可能不是最新的(不保證強一致性)。除此以外，Eureka還有一種自我保護機制，若是再15分鐘內超過85%的節點都沒有正常的心跳，那麼Eureka就認爲客戶端與註冊中心出現了網絡故障，此時會出現如下幾種狀況：

一、Eureka再也不從註冊列表中移除由於長時間沒有收到心跳而應該過時的服務

二、Eureka任然可以提供服務註冊和查詢請求，可是佔時不會將註冊的服務同步到其餘節點上(即保證當前節點依然可用)

三、當網絡穩定時，當前實例新的註冊信息纔會被同步到其它節點上

結論：Eureka能夠很好的應對因網絡故障致使部分節點失去聯繫的狀況，而不會像Zookeeper那樣使整個註冊服務癱瘓。