Eureka比Zookeeper好在哪裏？

 

Eureka遵照AP，Zookeeper遵照CP

RDBMS（oracle/mysql、sqlServer） ====> ACID， 關係型數據庫遵循ACID原則；

NoSQL（redis/mongodb）====> CAP

 1、ACID的介紹

ACID分別爲：

原子性（Automicity）：事務裏面的全部操做，要麼所有作完，要麼全不作；事務成功的條件是事務裏面的全部操做都成功，只要有一個操做失敗，整個事務就失敗，須要回滾；

一致性（Consistency）：數據庫要一直處於一致的狀態，事務的運行不會改變數據庫本來的一致性約束；也就是說：若是事務是併發多個，系統也必須如同串行事務同樣操做。其主要特徵是保護性和不變性(Preserving an Invariant)，以轉帳案例爲例，假設有五個帳戶，每一個帳戶餘額是100元，那麼五個帳戶總額是500元，若是在這個5個帳戶之間同時發生多個轉帳，不管併發多少個，好比在A與B帳戶之間轉帳5元，在C與D帳戶之間轉帳10元，在B與E之間轉帳15元，五個帳戶總額也應該仍是500元，這就是保護性和不變性。

隔離性（Isolation）： 併發的事務之間不會互相影響；

持久性（Durability）：在事務完成之後，該事務對數據庫所做的更改便持久的保存在數據庫之中，並不會被回滾。

 

2、CAP的介紹

CAP分別爲：強制一致性（Consistency），可用性（Availability），分區容錯性（Partition tolerance）：

CAP的3進2：任何一個分佈式系統中，沒法同時知足CAP3個原則，最多隻能知足其中的2個；

CAP的理論核心：任何一個分佈式系統中，沒法同時知足強制一致性、可用性、分區容錯性這3個需求；所以，根據CAP原則將NoSQL 數據庫分紅知足CA原則、CP原則、AP原則三大類：

CA原則：單點集羣，知足一致性、可用性的原則，一般在擴展上不太強；

CP原則：知足一致性、分區容錯的系統，一般性能不是特別高；

AP原則：知足可用、分區容錯的系統，一般對一致性要求低一點；

因爲當前的網絡硬件確定會出現延遲丟包的問題，因此分區容錯性是咱們必須實現的，因此分佈式系統只能在強制一致性和可用性中權衡；

所以：Zookeeper保證的是CP，Eureka保證的是AP；

當向註冊中心查詢服務列表時，咱們能夠容忍服務返回的是幾分鐘以前的數據，可是咱們不能容忍服務之間Down掉不可用。也就是說服務的註冊功能對可用性的要求高於一致性。

可是Zookeeper中會出現一種狀況，當master節點由於網絡故障和其餘節點失去聯繫了時，剩餘的節點會從新選舉leader。可是選舉leader的時間太長，30~120s，並且選舉期間整個Zookeeper集羣是不可用的，這就致使選舉期間註冊服務癱瘓。在雲部署的環境下，因網絡問題使得Zookeeper的master失去聯繫可能性是很大的，雖然最後服務可以恢復，可是較長時間的選舉致使註冊的長期不可用是不能容忍的；

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

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

（2）Eureka仍然可以接收新的服務註冊和查詢的請求，可是不會被同步到其餘節點上去（即保證當前節點依然可用）；

（3）當網絡穩定時，當前實例新的註冊信息會被同步到其餘節點上去；

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