Eureka和zookeeper都提供服務(wù)注冊與發(fā)現(xiàn)功能，兩者有什么區(qū)別？

Zookeeper保證了CP(C：一致性，P：分區(qū)容錯性)，Eureka保證了AP(A：高可用，P：分區(qū) 容錯)

1、Zookeeper—–當向注冊中心查詢服務(wù)列表時，我們可以容忍注冊中心返回的是幾分鐘以前的信息，但不能容忍直接down掉不可用的。也就是說服務(wù)注冊功能對高可用性要求比較 高，但是zk會出現(xiàn)這樣的一種情況，當master節(jié)點因為網(wǎng)絡(luò)故障與其他節(jié)點失去聯(lián)系時，剩 余的節(jié)點會重新選leader。問題在于，選取leader的時間過長(30~120s)，且選取期間zk集群 都不可用，這樣就會導(dǎo)致選取期間注冊服務(wù)癱瘓。在云部署的環(huán)境下，因網(wǎng)絡(luò)問題使得zk集群 失去master節(jié)點是較大概率會發(fā)生的事，雖然服務(wù)最終恢復(fù)，但是漫長的選擇時間導(dǎo)致的注冊 長期不可用是不能容忍的

2、Eureka則看明白這一點，因此再設(shè)計的優(yōu)先保證了高可用性。Eureka各個節(jié)點都是平等 的，幾個節(jié)點掛掉不會影響到正常節(jié)點的工作，剩余的節(jié)點依然可以提供注冊和查詢服務(wù)。而 Eureka的客戶端再向某個Eureka注冊時如果發(fā)現(xiàn)連接失敗，則會自動切換至其他節(jié)點，只要 有一臺Eureka還在，就能保證注冊服務(wù)的可用(保證可用性)，只不過查到的信息可能不是最新 的(不保證一致性)。除此之外Eureka還有一種自我保護機制，如果在15分鐘內(nèi)超過85%的節(jié) 點都沒有正常心跳，那么Eureka就認為客戶端與注冊中心出現(xiàn)了網(wǎng)絡(luò)故障，此時就會出現(xiàn)以下 幾種情況：

1)Eureka不再從注冊列表移除因為長時間沒收到心跳而應(yīng)該過期的服務(wù)

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

3)當網(wǎng)絡(luò)穩(wěn)定時，當前實例新的注冊信息會被同步到其它節(jié)點中 Eureka還有客戶端緩存功能(Eureka分為客戶端程序和服務(wù)器端程序兩個部分，客戶端程序負 責向外提供注冊與發(fā)現(xiàn)服務(wù)接口)。所以即便Eureka集群中所有節(jié)點都失效，或者發(fā)生網(wǎng)絡(luò)分 隔故障導(dǎo)致客戶端不能訪問任何一臺Eureka服務(wù)器;Eureka服務(wù)的消費者任然可以通過 Eureka客戶端緩存來獲取所有的服務(wù)注冊信息。甚至最極端的環(huán)境下，所有正常的Eureka節(jié) 點都不對請求產(chǎn)生響應(yīng)也沒有更好的服務(wù)器解決方案來解決這種問題時;得益于Eureka的客戶 端緩存技術(shù)，消費者服務(wù)仍然可以通過Eureka客戶端查詢與獲取注冊服務(wù)信息，這點很重要， 因此Eureka可以很好的應(yīng)對網(wǎng)絡(luò)故障導(dǎo)致部分節(jié)點失去聯(lián)系的情況，而不像Zookeeper那樣 使整個注冊服務(wù)癱瘓。

Zookeeper數(shù)據(jù)發(fā)布與訂閱主要應(yīng)用場景有哪些？

ZooKeeper在集群Master選舉中應(yīng)用介紹

Spring eureka原理介紹【微服務(wù)架構(gòu)基礎(chǔ)】

Spring Cloud微服務(wù)架構(gòu)的特點

傳智教育java高級軟件工程師培訓(xùn)