Zookeeper和Eureka的區(qū)別是什么

這篇文章主要講解了“Zookeeper和Eureka的區(qū)別是什么”，文中的講解內(nèi)容簡(jiǎn)單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來(lái)研究和學(xué)習(xí)“Zookeeper和Eureka的區(qū)別是什么”吧！

CAP定理

在分布式系統(tǒng)的發(fā)展中，影響最大的莫過(guò)于CAP定理了，是分布式系統(tǒng)發(fā)展的理論基石。

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 2000年，加州大學(xué)的計(jì)算機(jī)科學(xué)家 Eric Brewer提出了CAP猜想

3. 2002 年，麻省理工學(xué)院的 Seth Gilbert 和 Nancy Lynch 從理論上證明了 CAP 猜想，CAP猜想成為了CAP定理

「CAP定理，簡(jiǎn)單來(lái)說(shuō)就是分布式系統(tǒng)不可能同時(shí)滿足Consistency 一致性、Availability 可用性、Partition Tolerance  分區(qū)容錯(cuò)性三個(gè)要素」

Consistency 一致性

一致性的含義為，在節(jié)點(diǎn)的任意時(shí)刻，訪問(wèn)任意節(jié)點(diǎn)返回的數(shù)據(jù)是一致的。即Client端寫入一個(gè)數(shù)據(jù)后，Server端將數(shù)據(jù)同步到整個(gè)系統(tǒng)，從而保證系統(tǒng)的數(shù)據(jù)都相同

Availability 可用性

可用性的含義為，集群能夠?qū)τ脩舻恼?qǐng)求給予響應(yīng)。

Partition Tolerance 分區(qū)容錯(cuò)性

分區(qū)容錯(cuò)的含義為，當(dāng)出現(xiàn)分區(qū)故障時(shí)，系統(tǒng)仍要對(duì)外提供服務(wù)。分布式系統(tǒng)中，每個(gè)服務(wù)節(jié)點(diǎn)都是不可靠的，當(dāng)某些節(jié)點(diǎn)出現(xiàn)異常時(shí)，或者節(jié)點(diǎn)之間的通訊產(chǎn)生異常時(shí)，整個(gè)系統(tǒng)就產(chǎn)生了分區(qū)問(wèn)題，分布式系統(tǒng)中分區(qū)問(wèn)題是客觀存在的。

CAP權(quán)衡

CA

系統(tǒng)選擇CA，即不支持分區(qū)容錯(cuò)，只支持一致性和可用性。意味著不允許出現(xiàn)分區(qū)異常，網(wǎng)絡(luò)一致處于理想狀態(tài)。但是分布式系統(tǒng)之間網(wǎng)絡(luò)異常是客觀存在的，如果避免了P，只能把分布式系統(tǒng)退回到單實(shí)例系統(tǒng)。

CP

因?yàn)榉植际较到y(tǒng)P是客觀存在的，所以我們要在CP和AP之間進(jìn)行抉擇。

在網(wǎng)絡(luò)分區(qū)發(fā)生時(shí)，兩個(gè)分布式節(jié)點(diǎn)之間無(wú)法進(jìn)行通信，我們對(duì)一個(gè)節(jié)點(diǎn)進(jìn)行的修改操作將無(wú)法同步到另外一個(gè)節(jié)點(diǎn)，所以數(shù)據(jù)的「一致性」將無(wú)法滿足，因?yàn)閮蓚€(gè)分布式節(jié)點(diǎn)的數(shù)據(jù)不再保持一致。除非我們犧牲「可用性」，也就是暫停分布式節(jié)點(diǎn)服務(wù)，在網(wǎng)絡(luò)分區(qū)發(fā)生時(shí)，不再提供修改數(shù)據(jù)的功能，直到網(wǎng)絡(luò)狀況完全恢復(fù)正常再繼續(xù)對(duì)外提供服務(wù)

「當(dāng)選擇CP時(shí)，相當(dāng)于放棄系統(tǒng)的可用性，換取一致性」。zookeeper是選擇了CP的系統(tǒng)

在zookeeper集群中，有如下三種角色

在Leader服務(wù)器失效時(shí)，會(huì)重新從Follower服務(wù)器中選舉一個(gè)新的服務(wù)器作為L(zhǎng)eader服務(wù)器?！冈谥匦逻x舉Leader服務(wù)器的過(guò)程中，事務(wù)請(qǐng)求會(huì)被掛起，選舉完Leader服務(wù)器之后才會(huì)執(zhí)行這些請(qǐng)求」。即為了保證一致性，放棄了系統(tǒng)的可用性

AP

「當(dāng)選擇AP時(shí)，相當(dāng)于放棄系統(tǒng)一致性，換取可用性」。eureka是選擇了AP的系統(tǒng)

和zookeeper集群中有三種角色不同的是，eureka集群中每個(gè)節(jié)點(diǎn)扮演相同的角色，他們通過(guò)互相注冊(cè)的方式來(lái)感知對(duì)方的存在，當(dāng)有注冊(cè)信息時(shí)，他們會(huì)同步給集群內(nèi)的其他節(jié)點(diǎn)。

下面我從源碼角度分析一下eureka是如何放棄一致性來(lái)保證可用性的(放心，不會(huì)放源碼的，說(shuō)一下大概思路。源碼也比較簡(jiǎn)單，有興趣的可以看我寫的博客https://blog.csdn.net/zzti_erlie/article/details/104088914)

eureka注冊(cè)中心的信息保存在AbstractInstanceRegistry類的成員變量中

// AbstractInstanceRegistry private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry  = new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

就是一個(gè)雙層map，這個(gè)雙層map也很好理解。最外層是服務(wù)名，里面是一個(gè)具體的實(shí)例名

當(dāng)有服務(wù)往eureka上注冊(cè)時(shí)，注冊(cè)信息會(huì)被保存在map中，同時(shí)會(huì)把信息同步給其他的節(jié)點(diǎn)。此時(shí)有可能有些節(jié)點(diǎn)不可用了，或者網(wǎng)絡(luò)故障，并沒有收到信息，此時(shí)集群節(jié)點(diǎn)內(nèi)的信息可能是不一致的。

當(dāng)客戶端從某個(gè)eureka節(jié)點(diǎn)獲取信息失敗，或者注冊(cè)失敗，會(huì)自動(dòng)切換到另一個(gè)eureka節(jié)點(diǎn)。只要有一臺(tái)eureka節(jié)點(diǎn)可用，就能保證注冊(cè)服務(wù)可用。

Zookeeper和Eureka的區(qū)別

最后總結(jié)一下兩者的區(qū)別

感謝各位的閱讀，以上就是“Zookeeper和Eureka的區(qū)別是什么”的內(nèi)容了，經(jīng)過(guò)本文的學(xué)習(xí)后，相信大家對(duì)Zookeeper和Eureka的區(qū)別是什么這一問(wèn)題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！