Kafka對Zookeeper的迫切需求是什么

本篇內(nèi)容介紹了“Kafka對Zookeeper的迫切需求是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

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

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

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

上述場景中有一個非常重要的功能Leader選舉，如何選舉出一個主節(jié)點、并支持主節(jié)點宕機后自動觸發(fā)重新選舉，實現(xiàn)主從自動切換，實現(xiàn)高可用。

使用Zookeeper提供的臨時順序節(jié)點與事件監(jiān)聽機制，能非常輕松的實現(xiàn)Leader選舉。

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

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

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

客戶端判斷創(chuàng)建的節(jié)點的序號是否為/app/order-service/leader中序號最小的節(jié)點，如果是則成為Leader，對外提供服務;

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

回顧上述場景，借助Zookeeper能非常輕松的實現(xiàn)選主，為應用提高可用帶來簡便性，主要是利用了Zookeeper的幾個特性：

• 臨時節(jié)點

臨時節(jié)點是與會話關聯(lián)的，一點創(chuàng)建該臨時節(jié)點的會話結(jié)束，與之會被自動刪除，無需應用方人工刪除。

• 順序節(jié)點

• 事件機制

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

2、Kafka對Zookeeper的迫切需求

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

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

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

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

3、Zookeeper的致命弱點

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

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

Zookeeper集群中也存在所謂的Leader節(jié)點和從節(jié)點，Leader節(jié)點負責寫，Leader與從節(jié)點可用接受讀請求，但在Zookeeper內(nèi)部節(jié)點在選舉時整個Zookeeper無法對外提供服務。當然正常情況下選舉會非?？欤诋惓Ｇ闆r下就不好說了，例如Zookeeper節(jié)點發(fā)生full  Gc，此時造成的影響將是毀滅性的。

Zookeeper節(jié)點如果頻繁發(fā)生Full Gc，此時與客戶端的會話將超時，由于此時無法響應客戶端的心跳請求(Stop  World)，從而與會話相關聯(lián)的臨時節(jié)點將被刪除，注意，此時是所有的臨時節(jié)點會被刪除，Zookeeper依賴的事件通知機制將失效，整個集群的選舉服務將失效。

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

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

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

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

“Kafka對Zookeeper的迫切需求是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！