Eureka的優(yōu)勢(shì)

1奥此、在Eureka平臺(tái)中，如果某臺(tái)服務(wù)器宕機(jī)悼潭，Eureka不會(huì)有類(lèi)似于ZooKeeper的選舉leader的過(guò)程潮酒；客戶端請(qǐng)求會(huì)自動(dòng)切換到新的Eureka節(jié)點(diǎn)；當(dāng)宕機(jī)的服務(wù)器重新恢復(fù)后士修，Eureka會(huì)再次將其納入到服務(wù)器集群管理之中枷遂；而對(duì)于它來(lái)說(shuō)，所有要做的無(wú)非是同步一些新的服務(wù)注冊(cè)信息而已棋嘲。所以酒唉，再也不用擔(dān)心有“掉隊(duì)”的服務(wù)器恢復(fù)以后，會(huì)從Eureka服務(wù)器集群中剔除出去的風(fēng)險(xiǎn)了沸移。Eureka甚至被設(shè)計(jì)用來(lái)應(yīng)付范圍更廣的網(wǎng)絡(luò)分割故障痪伦，并實(shí)現(xiàn)“0”宕機(jī)維護(hù)需求。（多個(gè)zookeeper之間網(wǎng)絡(luò)出現(xiàn)問(wèn)題,造成出現(xiàn)多個(gè)leader雹锣，發(fā)生腦裂）當(dāng)網(wǎng)絡(luò)分割故障發(fā)生時(shí)网沾，每個(gè)Eureka節(jié)點(diǎn)，會(huì)持續(xù)的對(duì)外提供服務(wù)（注：ZooKeeper不會(huì)）：接收新的服務(wù)注冊(cè)同時(shí)將它們提供給下游的服務(wù)發(fā)現(xiàn)請(qǐng)求蕊爵。這樣一來(lái)辉哥，就可以實(shí)現(xiàn)在同一個(gè)子網(wǎng)中（same side of partition），新發(fā)布的服務(wù)仍然可以被發(fā)現(xiàn)與訪問(wèn)攒射。

2醋旦、正常配置下，Eureka內(nèi)置了心跳服務(wù)会放，用于淘汰一些“瀕死”的服務(wù)器饲齐；如果在Eureka中注冊(cè)的服務(wù)，它的“心跳”變得遲緩時(shí)咧最，Eureka會(huì)將其整個(gè)剔除出管理范圍（這點(diǎn)有點(diǎn)像ZooKeeper的做法）捂人。這是個(gè)很好的功能御雕，但是當(dāng)網(wǎng)絡(luò)分割故障發(fā)生時(shí)，這也是非常危險(xiǎn)的滥搭；因?yàn)樗岣伲切┮驗(yàn)榫W(wǎng)絡(luò)問(wèn)題（注：心跳慢被剔除了）而被剔除出去的服務(wù)器本身是很”健康“的，只是因?yàn)榫W(wǎng)絡(luò)分割故障把Eureka集群分割成了獨(dú)立的子網(wǎng)而不能互訪而已瑟匆。

幸運(yùn)的是福青，Netflix考慮到了這個(gè)缺陷。如果Eureka服務(wù)節(jié)點(diǎn)在短時(shí)間里丟失了大量的心跳連接（注：可能發(fā)生了網(wǎng)絡(luò)故障）脓诡，那么這個(gè)Eureka節(jié)點(diǎn)會(huì)進(jìn)入”自我保護(hù)模式“无午，同時(shí)保留那些“心跳死亡“的服務(wù)注冊(cè)信息不過(guò)期。此時(shí)祝谚，這個(gè)Eureka節(jié)點(diǎn)對(duì)于新的服務(wù)還能提供注冊(cè)服務(wù)宪迟，對(duì)于”死亡“的仍然保留，以防還有客戶端向其發(fā)起請(qǐng)求交惯。當(dāng)網(wǎng)絡(luò)故障恢復(fù)后次泽，這個(gè)Eureka節(jié)點(diǎn)會(huì)退出”自我保護(hù)模式“。所以Eureka的哲學(xué)是席爽，同時(shí)保留”好數(shù)據(jù)“與”壞數(shù)據(jù)“總比丟掉任何”好數(shù)據(jù)“要更好意荤，所以這種模式在實(shí)踐中非常有效。

3只锻、Eureka還有客戶端緩存功能（注：Eureka分為客戶端程序與服務(wù)器端程序兩個(gè)部分玖像，客戶端程序負(fù)責(zé)向外提供注冊(cè)與發(fā)現(xiàn)服務(wù)接口）。所以即便Eureka集群中所有節(jié)點(diǎn)都失效齐饮，或者發(fā)生網(wǎng)絡(luò)分割故障導(dǎo)致客戶端不能訪問(wèn)任何一臺(tái)Eureka服務(wù)器捐寥；Eureka服務(wù)的消費(fèi)者仍然可以通過(guò)Eureka客戶端緩存來(lái)獲取現(xiàn)有的服務(wù)注冊(cè)信息。甚至最極端的環(huán)境下祖驱，所有正常的Eureka節(jié)點(diǎn)都不對(duì)請(qǐng)求產(chǎn)生相應(yīng)握恳，也沒(méi)有更好的服務(wù)器解決方案來(lái)解決這種問(wèn)題

時(shí)；得益于Eureka的客戶端緩存技術(shù)捺僻，消費(fèi)者服務(wù)仍然可以通過(guò)Eureka客戶端查詢(xún)與獲取注冊(cè)服務(wù)信息乡洼，這點(diǎn)很重要。

4匕坯、Eureka的構(gòu)架保證了它能夠成為Service發(fā)現(xiàn)服務(wù)束昵。它相對(duì)與ZooKeeper來(lái)說(shuō)剔除了Leader節(jié)點(diǎn)的選取或者事務(wù)日志機(jī)制，這樣做有利于減少使用者維護(hù)的難度也保證了Eureka的在運(yùn)行時(shí)的健壯性醒颖。而且Eureka就是為發(fā)現(xiàn)服務(wù)所設(shè)計(jì)的妻怎，它有獨(dú)立的客戶端程序庫(kù)壳炎，同時(shí)提供心跳服務(wù)泞歉、服務(wù)健康監(jiān)測(cè)逼侦、自動(dòng)發(fā)布服務(wù)與自動(dòng)刷新緩存的功能。但是腰耙，如果使用ZooKeeper你必須自己來(lái)實(shí)現(xiàn)這些功能榛丢。Eureka的所有庫(kù)都是開(kāi)源的，所有人都能看到與使用這些源代碼挺庞，這比那些只有一兩個(gè)人能看或者維護(hù)的客戶端庫(kù)要好晰赞。

5、維護(hù)Eureka服務(wù)器也非常的簡(jiǎn)單选侨，比如掖鱼，切換一個(gè)節(jié)點(diǎn)只需要在現(xiàn)有EIP下移除一個(gè)現(xiàn)有的節(jié)點(diǎn)然后添加一個(gè)新的就行。Eureka提供了一個(gè)web-based的圖形化的運(yùn)維界面援制，在這個(gè)界面中可以查看Eureka所管理的注冊(cè)服務(wù)的運(yùn)行狀態(tài)信息：是否健康戏挡，運(yùn)行日志等。Eureka甚至提供了Restful-API接口晨仑，方便第三方程序集成Eureka的功能褐墅。

ZooKeeper的劣勢(shì)

在分布式系統(tǒng)領(lǐng)域有個(gè)著名的CAP定理（C-數(shù)據(jù)一致性；A-服務(wù)可用性洪己；P-服務(wù)對(duì)網(wǎng)絡(luò)分區(qū)故障的容錯(cuò)性妥凳，這三個(gè)特性在任何分布式系統(tǒng)中不能同時(shí)滿足，最多同時(shí)滿足兩個(gè)）答捕；ZooKeeper是個(gè)CP的逝钥，即任何時(shí)刻對(duì)ZooKeeper的訪問(wèn)請(qǐng)求能得到一致的數(shù)據(jù)結(jié)果，同時(shí)系統(tǒng)對(duì)網(wǎng)絡(luò)分割具備容錯(cuò)性拱镐；但是它不能保證每次服務(wù)請(qǐng)求的可用性（注：也就是在極端環(huán)境下晌缘，ZooKeeper可能會(huì)丟棄一些請(qǐng)求，消費(fèi)者程序需要重新請(qǐng)求才能獲得結(jié)果）痢站。但是別忘了磷箕，ZooKeeper是分布式協(xié)調(diào)服務(wù)，它的職責(zé)是保證數(shù)據(jù)（注：配置數(shù)據(jù)阵难，狀態(tài)數(shù)據(jù)）在其管轄下的所有服務(wù)之間保持同步岳枷、一致；所以就不難理解為什么ZooKeeper被設(shè)計(jì)成CP而不是AP特性的了呜叫，如果是AP的空繁，那么將會(huì)帶來(lái)恐怖的后果（注：ZooKeeper就像交叉路口的信號(hào)燈一樣，你能想象在交通要道突然信號(hào)燈失靈的情況嗎朱庆？）盛泡。而且，作為ZooKeeper的核心實(shí)現(xiàn)算法Zab娱颊，就是解決了分布式系統(tǒng)下數(shù)據(jù)如何在多個(gè)服務(wù)之間保持同步問(wèn)題的傲诵。

1凯砍、對(duì)于Service發(fā)現(xiàn)服務(wù)來(lái)說(shuō)就算是返回了包含不實(shí)的信息的結(jié)果也比什么都不返回要好；再者拴竹，對(duì)于Service發(fā)現(xiàn)服務(wù)而言悟衩，寧可返回某服務(wù)5分鐘之前在哪幾個(gè)服務(wù)器上可用的信息，也不能因?yàn)闀簳r(shí)的網(wǎng)絡(luò)故障而找不到可用的服務(wù)器栓拜，而不返回任何結(jié)果座泳。所以說(shuō)，用ZooKeeper來(lái)做Service發(fā)現(xiàn)服務(wù)是肯定錯(cuò)誤的幕与，如果你這么用就慘了挑势！

如果被用作Service發(fā)現(xiàn)服務(wù)，ZooKeeper本身并沒(méi)有正確的處理網(wǎng)絡(luò)分割的問(wèn)題啦鸣；而在云端薛耻，網(wǎng)絡(luò)分割問(wèn)題跟其他類(lèi)型的故障一樣的確會(huì)發(fā)生；所以最好提前對(duì)這個(gè)問(wèn)題做好100%的準(zhǔn)備赏陵。就像Jepsen在ZooKeeper網(wǎng)站上發(fā)布的博客中所說(shuō)：在ZooKeeper中饼齿，如果在同一個(gè)網(wǎng)絡(luò)分區(qū)（partition）的節(jié)點(diǎn)數(shù)（nodes）數(shù)達(dá)不到ZooKeeper選取Leader節(jié)點(diǎn)的“法定人數(shù)”時(shí)，它們就會(huì)從ZooKeeper中斷開(kāi)蝙搔，當(dāng)然同時(shí)也就不能提供Service發(fā)現(xiàn)服務(wù)了缕溉。

2、ZooKeeper下所有節(jié)點(diǎn)不可能保證任何時(shí)候都能緩存所有的服務(wù)注冊(cè)信息吃型。如果ZooKeeper下所有節(jié)點(diǎn)都斷開(kāi)了证鸥，或者集群中出現(xiàn)了網(wǎng)絡(luò)分割的故障（注：由于交換機(jī)故障導(dǎo)致交換機(jī)底下的子網(wǎng)間不能互訪）；那么ZooKeeper會(huì)將它們都從自己管理范圍中剔除出去勤晚，外界就不能訪問(wèn)到這些節(jié)點(diǎn)了枉层，即便這些節(jié)點(diǎn)本身是“健康”的，可以正常提供服務(wù)的赐写；所以導(dǎo)致到達(dá)這些節(jié)點(diǎn)的服務(wù)請(qǐng)求被丟失了鸟蜡。（注：這也是為什么ZooKeeper不滿足CAP中A的原因）

3、更深層次的原因是挺邀，ZooKeeper是按照CP原則構(gòu)建的揉忘，也就是說(shuō)它能保證每個(gè)節(jié)點(diǎn)的數(shù)據(jù)保持一致，而為ZooKeeper加上緩存的做法的目的是為了讓ZooKeeper變得更加可靠（available）端铛；但是泣矛，ZooKeeper設(shè)計(jì)的本意是保持節(jié)點(diǎn)的數(shù)據(jù)一致，也就是CP禾蚕。所以您朽，這樣一來(lái)，你可能既得不到一個(gè)數(shù)據(jù)一致的（CP）也得不到一個(gè)高可用的（AP）的Service發(fā)現(xiàn)服務(wù)了换淆；因?yàn)榛┳埽@相當(dāng)于你在一個(gè)已有的CP系統(tǒng)上強(qiáng)制栓了一個(gè)AP的系統(tǒng)几颜，這在本質(zhì)上就行不通的！一個(gè)Service發(fā)現(xiàn)服務(wù)應(yīng)該從一開(kāi)始就被設(shè)計(jì)成高可用的才行魂奥！

4、如果拋開(kāi)CAP原理不管易猫，正確的設(shè)置與維護(hù)ZooKeeper服務(wù)就非常的困難耻煤；錯(cuò)誤會(huì)經(jīng)常發(fā)生，導(dǎo)致很多工程被建立只是為了減輕維護(hù)ZooKeeper的難度准颓。這些錯(cuò)誤不僅存在與客戶端而且還存在于ZooKeeper服務(wù)器本身哈蝇。Knewton平臺(tái)很多故障就是由于ZooKeeper使用不當(dāng)而導(dǎo)致的。那些看似簡(jiǎn)單的操作攘已，如：正確的重建觀察者（reestablishing watcher）炮赦、客戶端Session與異常的處理與在ZK窗口中管理內(nèi)存都是非常容易導(dǎo)致ZooKeeper出錯(cuò)的。同時(shí)样勃，我們確實(shí)也遇到過(guò)ZooKeeper的一些經(jīng)典bug：ZooKeeper-1159 與ZooKeeper-1576吠勘；我們甚至在生產(chǎn)環(huán)境中遇到過(guò)ZooKeeper選舉Leader節(jié)點(diǎn)失敗的情況。這些問(wèn)題之所以會(huì)出現(xiàn)峡眶，在于ZooKeeper需要管理與保障所管轄服務(wù)群的Session與網(wǎng)絡(luò)連接資源（注：這些資源的管理在分布式系統(tǒng)環(huán)境下是極其困難的）剧防；但是它不負(fù)責(zé)管理服務(wù)的發(fā)現(xiàn)，所以使用ZooKeeper當(dāng)Service發(fā)現(xiàn)服務(wù)得不償失辫樱。

一個(gè)集群有3臺(tái)機(jī)器峭拘，掛了一臺(tái)后的影響是什么？掛了兩臺(tái)呢狮暑？

掛了一臺(tái)：掛了一臺(tái)后就是收不到其中一臺(tái)的投票鸡挠，但是有兩臺(tái)可以參與投票，按照上面的邏輯搬男，它們開(kāi)始都投給自己拣展，后來(lái)按照選舉的原則，兩個(gè)人都投票給其中一個(gè)缔逛，那么就有一個(gè)節(jié)點(diǎn)獲得的票等于2瞎惫，2 > (3/2)=1 的，超過(guò)了半數(shù)译株，這個(gè)時(shí)候是能選出leader的瓜喇。

掛了兩臺(tái)： 掛了兩臺(tái)后，怎么弄也只能獲得一張票歉糜， 1 不大于 (3/2)=1的乘寒，這樣就無(wú)法選出一個(gè)leader了。

ZAB（ZooKeeper

Atomic Broadcast

）?全稱(chēng)為：原子消息廣播協(xié)議匪补；ZAB可以說(shuō)是在Paxos算法基礎(chǔ)上進(jìn)行了擴(kuò)展改造而來(lái)的伞辛，ZAB協(xié)議設(shè)計(jì)了支持崩潰恢復(fù)烂翰，ZooKeeper使用單一主進(jìn)程Leader用于處理客戶端所有事務(wù)請(qǐng)求，采用ZAB協(xié)議將服務(wù)器數(shù)狀態(tài)以事務(wù)形式廣播到所有Follower上蚤氏；由于事務(wù)間可能存在著依賴(lài)關(guān)系甘耿，ZAB協(xié)議保證Leader廣播的變更序列被順序的處理，：一個(gè)狀態(tài)被處理那么它所依賴(lài)的狀態(tài)也已經(jīng)提前被處理竿滨；ZAB協(xié)議支持的崩潰恢復(fù)可以保證在Leader進(jìn)程崩潰的時(shí)候可以重新選出Leader并且保證數(shù)據(jù)的完整性佳恬；

過(guò)半數(shù)（>=N/2+1）?的Follower反饋信息后，Leader將再次向集群內(nèi)Follower廣播Commit信息于游，Commit為將之前的Proposal提交毁葱；