自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

知其然而知其所以然,為什么Kafka在2.8版本中會(huì)“拋棄”Zookeeper

開(kāi)發(fā) 架構(gòu) Kafka
相信大家最近一定關(guān)注到一款重量級(jí)消息中間件Kafka發(fā)布了2.8版本,并且正式移除了對(duì)Zookeeper的依賴,背后的設(shè)計(jì)哲學(xué)是什么呢?僅僅只是減少了一個(gè)外部依賴嗎?

[[394844]]

相信大家最近一定關(guān)注到一款重量級(jí)消息中間件Kafka發(fā)布了2.8版本,并且正式移除了對(duì)Zookeeper的依賴,背后的設(shè)計(jì)哲學(xué)是什么呢?僅僅只是減少了一個(gè)外部依賴嗎?

答案顯然不會(huì)這么簡(jiǎn)單,容我慢慢道來(lái)。

在解答為什么之前,我覺(jué)得非常有必要先來(lái)闡述一下Zookeeper的經(jīng)典使用場(chǎng)景。

1、Zookeeper的經(jīng)典使用場(chǎng)景

zookeeper是伴隨著大數(shù)據(jù)、分布式領(lǐng)域的興起。大數(shù)據(jù)中的一個(gè)非常重要的議題是如何使用眾多廉價(jià)的機(jī)器來(lái)實(shí)現(xiàn)可靠存儲(chǔ)。

所謂廉價(jià)的機(jī)器就是發(fā)生故障的概率非常大,但單臺(tái)的成本也非常低,分布式領(lǐng)域希望使用多臺(tái)機(jī)器組成一個(gè)集群,將數(shù)據(jù)存儲(chǔ)在多臺(tái)機(jī)器上(副本),為了方便實(shí)現(xiàn)數(shù)據(jù)一致性,通常需要從一個(gè)復(fù)制組中挑選一臺(tái)主節(jié)點(diǎn)用戶處理數(shù)據(jù)的讀寫(xiě),其他節(jié)點(diǎn)從主節(jié)點(diǎn)拷貝數(shù)據(jù),當(dāng)主節(jié)點(diǎn)宕機(jī),需要自動(dòng)進(jìn)行重新選舉,實(shí)現(xiàn)高可用。

上述場(chǎng)景中有一個(gè)非常重要的功能Leader選舉,如何選舉出一個(gè)主節(jié)點(diǎn)、并支持主節(jié)點(diǎn)宕機(jī)后自動(dòng)觸發(fā)重新選舉,實(shí)現(xiàn)主從自動(dòng)切換,實(shí)現(xiàn)高可用。

使用Zookeeper提供的臨時(shí)順序節(jié)點(diǎn)與事件監(jiān)聽(tīng)機(jī)制,能非常輕松的實(shí)現(xiàn)Leader選舉。

上面的t1,t2可以理解為一個(gè)組織中的多個(gè)成員,能提供相同的服務(wù),但為了實(shí)現(xiàn)冷備效果(即同一時(shí)間只有一個(gè)成員對(duì)外提供服務(wù),我們稱之為L(zhǎng)eader,當(dāng)Leader宕機(jī)或停止服務(wù)后,該組織中的其他成名重新競(jìng)爭(zhēng)Leader,然后繼續(xù)對(duì)外提供服務(wù))。

正如上圖所示,Zookeeper是以集群部署的,能有效避免單點(diǎn)故障,并且集群內(nèi)部提供了對(duì)數(shù)據(jù)的強(qiáng)一致性。

當(dāng)成員需要競(jìng)爭(zhēng)Leader時(shí),借助Zookeeper的實(shí)現(xiàn)套路是向zookeeper中的一個(gè)數(shù)據(jù)節(jié)點(diǎn)(示例中為/app/order-service/leader)節(jié)點(diǎn)創(chuàng)建兩個(gè)子節(jié)點(diǎn),并且是順序的臨時(shí)節(jié)點(diǎn)。

客戶端判斷創(chuàng)建的節(jié)點(diǎn)的序號(hào)是否為/app/order-service/leader中序號(hào)最小的節(jié)點(diǎn),如果是則成為L(zhǎng)eader,對(duì)外提供服務(wù);

如果序號(hào)不是最小的,則向自己前置的注冊(cè)節(jié)點(diǎn)刪除事件,一旦Leader代表的進(jìn)程宕機(jī),它與Zookeeper的會(huì)話失效后,與之關(guān)聯(lián)的臨時(shí)節(jié)點(diǎn)會(huì)被刪除,一旦Leader創(chuàng)建的節(jié)點(diǎn)被刪除,其后繼節(jié)點(diǎn)會(huì)得到通知,從而再次觸發(fā)選主,選舉出新的Leader,繼續(xù)對(duì)外提供服務(wù),保質(zhì)服務(wù)的高可用性。

回顧上述場(chǎng)景,借助Zookeeper能非常輕松的實(shí)現(xiàn)選主,為應(yīng)用提高可用帶來(lái)簡(jiǎn)便性,主要是利用了Zookeeper的幾個(gè)特性:

  • 臨時(shí)節(jié)點(diǎn)

臨時(shí)節(jié)點(diǎn)是與會(huì)話關(guān)聯(lián)的,一點(diǎn)創(chuàng)建該臨時(shí)節(jié)點(diǎn)的會(huì)話結(jié)束,與之會(huì)被自動(dòng)刪除,無(wú)需應(yīng)用方人工刪除。

  • 順序節(jié)點(diǎn)
  • 事件機(jī)制

借助與事件機(jī)制,Zookeeper能及時(shí)通知存活的其他應(yīng)用節(jié)點(diǎn),重新觸發(fā)選舉,使得實(shí)現(xiàn)自動(dòng)主從切換變的非常簡(jiǎn)單。

2、Kafka對(duì)Zookeeper的迫切需求

Kafka中存在眾多的Leader選舉,熟悉Kafka的朋友應(yīng)該知道,一個(gè)主題可以擁有多個(gè)分區(qū)(數(shù)據(jù)分片),每一個(gè)數(shù)據(jù)分片可以配置多個(gè)副本,如何保證一個(gè)分區(qū)的數(shù)據(jù)在多個(gè)副本之間的一致性成為一個(gè)迫切的需求。

Kafka的實(shí)現(xiàn)套路就是一個(gè)分區(qū)的多個(gè)副本,從中選舉出一個(gè)Leader用來(lái)承擔(dān)客戶端的讀寫(xiě)請(qǐng)求,從節(jié)點(diǎn)從主節(jié)點(diǎn)處拷貝內(nèi)容,Leader節(jié)點(diǎn)根據(jù)數(shù)據(jù)在副本中成功寫(xiě)入情況,進(jìn)行抉擇來(lái)確定是否寫(xiě)入成功。

Kafka中topic的分區(qū)分布示意圖:

故此處需要進(jìn)行Leader選舉,而基于Zookeeper能輕松實(shí)現(xiàn),從此一拍即合,開(kāi)啟了一段“蜜月之旅”。

3、Zookeeper的致命弱點(diǎn)

Zookeeper是集群部署,只要集群中超過(guò)半數(shù)節(jié)點(diǎn)存活,即可提供服務(wù),例如一個(gè)由3個(gè)節(jié)點(diǎn)的Zookeeper,允許1個(gè)Zookeeper節(jié)點(diǎn)宕機(jī),集群仍然能提供服務(wù);一個(gè)由5個(gè)節(jié)點(diǎn)的Zookeeper,允許2個(gè)節(jié)點(diǎn)宕機(jī)。

但Zookeeper的設(shè)計(jì)是CP模型,即要保證數(shù)據(jù)的強(qiáng)一致性,必然在可用性方面做出犧牲。

Zookeeper集群中也存在所謂的Leader節(jié)點(diǎn)和從節(jié)點(diǎn),Leader節(jié)點(diǎn)負(fù)責(zé)寫(xiě),Leader與從節(jié)點(diǎn)可用接受讀請(qǐng)求,但在Zookeeper內(nèi)部節(jié)點(diǎn)在選舉時(shí)整個(gè)Zookeeper無(wú)法對(duì)外提供服務(wù)。當(dāng)然正常情況下選舉會(huì)非???,但在異常情況下就不好說(shuō)了,例如Zookeeper節(jié)點(diǎn)發(fā)生full Gc,此時(shí)造成的影響將是毀滅性的。

Zookeeper節(jié)點(diǎn)如果頻繁發(fā)生Full Gc,此時(shí)與客戶端的會(huì)話將超時(shí),由于此時(shí)無(wú)法響應(yīng)客戶端的心跳請(qǐng)求(Stop World),從而與會(huì)話相關(guān)聯(lián)的臨時(shí)節(jié)點(diǎn)將被刪除,注意,此時(shí)是所有的臨時(shí)節(jié)點(diǎn)會(huì)被刪除,Zookeeper依賴的事件通知機(jī)制將失效,整個(gè)集群的選舉服務(wù)將失效。

站在高可用性的角度,Kafka集群的可用性不僅取決于自身,還受到了外部組件的制約,從長(zhǎng)久來(lái)看,顯然都不是一個(gè)優(yōu)雅的方案。

隨著分布式領(lǐng)域相關(guān)技術(shù)的不斷完善,去中心化的思想逐步興起,去Zookeeper的呼聲也越來(lái)越高,在這個(gè)進(jìn)程中涌現(xiàn)了一個(gè)非常優(yōu)秀的算法:Raft協(xié)議。

Raft協(xié)議的兩個(gè)重要組成部分:Leader選舉、日志復(fù)制,而日志復(fù)制為多個(gè)副本提供數(shù)據(jù)強(qiáng)一致性提供了強(qiáng)一致性,并且一個(gè)顯著的特點(diǎn)是Raft節(jié)點(diǎn)是去中心化的架構(gòu),不依賴外部的組件,而是作為一個(gè)協(xié)議簇嵌入到應(yīng)用中的,即與應(yīng)用本身是融合為一體的。

再以Kafka Topic的分布圖舉例,引用Raft協(xié)議的示例圖如下:

關(guān)于Raft協(xié)議,本文并不打算深入進(jìn)行探討,但為選主提供了另外一種可行方案,而且還無(wú)需依賴第三方組件,何樂(lè)而不為呢?故最終Kafka在2.8版本中正式廢棄了Zookeeper,擁抱Raft。

責(zé)任編輯:武曉燕 來(lái)源: 中間件興趣圈
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)