Eureka和Zookeeper

CAP原則

說差別之前，先回顧一下資料庫的内容

資料庫類型	代表性資料庫	設計原則
RDBMS（關系型資料庫）	mysql、Oracle、SQL server	ACID（強調事務）
NOSQL（非關系型資料庫）	redis、mongdb	CAP（強調性能和擴充）

具體參見另一篇博文：

分布式資料庫CAP原理與ACID,CAP+BASE

差別

Zookeeper遵循的就是CP原則

Zookeeper在master節點發生故障時，剩餘節點會重新選舉出Leader，但是時間會有點長，并且在此期間整個叢集都是不可用的（服務注冊不上）。雖然最終系統會恢複（保證一緻性），但是等待時間過長這是使用者所不能忍受的。

Eureka遵循的是AP原則

Eureka的每個節點都是平等的，幾個節點出故障不會影響其它節點的服務注冊與發現功能，隻要有一個節點存活，系統就仍然可以工作（保證可用性）。

此外Eureka還具有自我保護機制。如果在15分鐘内85%的服務都沒有正常心跳，Eureka就會認為用戶端與注冊中心出了故障，就會出現一下幾種情況：

1. Eureka不再從服務注冊清單中移除長時間不發送心跳的服務資訊，而是會保留。
2. Eureka仍然能提供服務注冊與發現功能，但是不會同步到其他節點上，保證目前節點的可用性。
3. 當網絡恢複正常後，目前Eureka會把新的注冊資訊同步到其它Eureka節點上。