Kafka 作為一個流式數(shù)據(jù)平臺,對開發(fā)者提供了三種客戶端:生產(chǎn)者 / 消費者、連接器、流處理。本文著重分析這三種客戶端的線程模型??吹阶詈蟮耐ǔ6加畜@喜。
消費者的線程模型
0.8 版本以前的消費者客戶端會創(chuàng)建一個基于 ZK 的消費者連接器,一個消費者客戶端是一個 Java 進程,消費者可以訂閱多個主題,每個主題也可以多個線程。為了讓消息在多個節(jié)點被分布式地消費,提高消息處理的吞吐量,Kafka 允許多個消費者訂閱同一個主題,這些消費者需要滿足“一個分區(qū)只能被一個消費者中的一個線程處理”的限制條件。通常,我們會將同一份相同業(yè)務處理邏輯的應用程序部署在不同機器上,并且指定一個消費組編號。當不同機器上的消費者進程啟動后,所有這些消費者進程就組成了一個邏輯意義上的消費組。
新源網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián)建站,新源網(wǎng)站設(shè)計制作,有大型網(wǎng)站制作公司豐富經(jīng)驗。已為新源上千多家提供企業(yè)網(wǎng)站建設(shè)服務。企業(yè)網(wǎng)站搭建\成都外貿(mào)網(wǎng)站建設(shè)要多少錢,請找那個售后服務好的新源做網(wǎng)站的公司定做!
消費組中的消費者數(shù)量是動態(tài)變化的,當有新消費者加入消費組,或者舊消費者離開消費組,都會觸發(fā)基于 ZK 的消費組“再平衡”操作。當“再平衡”操作發(fā)生時,每個消費者都會在客戶端執(zhí)行分區(qū)分配算法,然后從全局的分配結(jié)果中獲取屬于自己的分區(qū)。它的缺點是消費者會和 ZK 產(chǎn)生頻繁的交互,造成 ZK 集群的壓力過大,并且容易產(chǎn)生羊群效應和腦裂等問題。
在 0.8 版本以后,Kafka 重新設(shè)計了客戶端,并且引入了“協(xié)調(diào)者”和“消費組管理協(xié)議”。新的消費者將“消費組管理協(xié)議”和“分區(qū)分配策略”進行了分離。協(xié)調(diào)者負責消費組的管理,而分區(qū)分配則會在消費組的一個主消費者中完成。采用這種方式,每個消費者都需要發(fā)送下面兩種請求給協(xié)調(diào)者。
加入組請求:協(xié)調(diào)者收集消費組的所有消費者,并選舉一個主消費者執(zhí)行分區(qū)分配工作。
同步組請求:主消費者完成分區(qū)分配,由協(xié)調(diào)者將分區(qū)的分配結(jié)果傳播給每個消費者。
新版本的消費者客戶端引入了一個客戶端協(xié)調(diào)者的抽象類,它的實現(xiàn)除了消費者的協(xié)調(diào)者,還有一個連接器的實現(xiàn)。
連接器的線程模型
Kafka 連接器的出現(xiàn)標準化了 Kafka 與各種外部存儲系統(tǒng)的數(shù)據(jù)同步。用戶開發(fā)和使用連接器就變得非常簡單,只需要在配置文件中定義連接器,就可以將外部系統(tǒng)的數(shù)據(jù)導入 Kafka 或?qū)?Kafka 數(shù)據(jù)導出到外部系統(tǒng)。如圖 1 所示,中間部分都是 Kafka 連接器的內(nèi)部組件,包括源連接器(Source Connector)和目標連接器(Sink Connector)。
圖 1 Kafka 連接器的源連接器與目標連接器
Kafka 連接器的單機模式會在一個進程內(nèi)啟動一個 Worker 以及所有的連接器和任務。分布式模式的每個進程都有一個 Worker,而連接器和任務則分別運行在各個節(jié)點上。圖 2 列舉了連接器和任務在不同 Worker 上的四種分布方式:
一個 Worker,一個源任務、一個目標任務
一個 Worker,兩個源任務、兩個目標任務
兩個 Worker,兩個源任務、兩個目標任務
三個 Worker,兩個源任務、兩個目標任務
圖 2 分布式模式的 Kafka 連接器集群
分布式模式下,不同 Worker 進程之間的協(xié)調(diào)工作類似于消費者的協(xié)調(diào)。消費者通過協(xié)調(diào)者獲取分配的分區(qū),Worker 也會通過協(xié)調(diào)者獲取分配的連接器與任務。如圖 3 所示,消費者客戶端和 Worker 客戶端為了加入到組管理中,分別通過客戶端的協(xié)調(diào)者對象來和服務端的消費組協(xié)調(diào)(GroupCoordinator)通信。
圖 3 消費者和 Worker 的工作都是通過協(xié)調(diào)者分配的
流處理的線程模型
Kafka 流處理的工作流程簡單來看分成三個步驟:消費者讀取輸入分區(qū)的數(shù)據(jù)、流式地處理每條數(shù)據(jù)、生產(chǎn)者將處理結(jié)果寫入輸出分區(qū),這里面步驟 1 也充分利用了“消費組管理協(xié)議”。Kafka 流處理的輸入數(shù)據(jù)源基于具有分布式分區(qū)模型的 Kafka 主題,它的線程模型主要由下面三個類組成:
流實例(KafkaStreams):通常一個節(jié)點(一臺機器)只運行一個流實例。
流線程(StreamThread):一個流實例可以配置多個流線程。
流任務(StreamTask):一個流線程可以運行多個流任務,根據(jù)輸入主題的分區(qū)數(shù)確定任務數(shù)。
如圖 4 所示,輸入主題有六個分區(qū),Kafka 流處理總共就會產(chǎn)生六個流任務。流實例可以動態(tài)擴展,流線程的個數(shù)也可以動態(tài)配置。圖中一共有三個流線程,則每個流線程會有兩個流任務,每個流任務都對應輸入主題的一個分區(qū)。
圖 4 Kafka 流處理的線程模型
Kafka 的流處理框架使用并行的線程模型處理輸入主題的數(shù)據(jù)集,這種設(shè)計思路和 Kafka 的消費者線程模型非常類似。消費者分配到訂閱主題的不同分區(qū),流處理框架的流任務也分配到輸入主題的不同分區(qū)。如圖 5 所示,輸入主題 1 的分區(qū) P1 和輸入主題 2 的分區(qū) P1 分配給流線程 1 的流任務,輸入主題 1 的分區(qū) P2 和輸入主題 2 的分區(qū) P2 分配給流線程 2 的流任務。流處理相比消費者,還會將拓撲的計算結(jié)果寫到輸出主題。
圖 5 消費者模型與流處理的線程模型
消費者和流處理的故障容錯機制也是類似的。如圖 6 所示,假設(shè)消費者 2 進程掛掉,它所持有的分區(qū)會被分配給同一個消費組中的消費者 1,這樣消費者 1 會分配到訂閱主題的所有分區(qū)。對于流處理而言,如果流線程 2 掛掉了,流線程 2 中的流任務會分配給流線程 1。即流線程 1 會運行兩個流任務,每個流任務分配的分區(qū)仍然保持不變。
圖 6 消費者與流處理的故障容錯機制
小 結(jié)
Kafka 客戶端抽象出來的的“組管理協(xié)議”充分運用在消費者、連接器、流處理三個使用場景中??蛻舳酥械南M者、連接器中的工作者、流處理中的流進程都可以看做“組”的一個成員。當增加或減少組成員時,在這個協(xié)議的約束下,每個組成員都可以獲取到最新的任務,從而做到無縫的任務遷移。一旦理解了“組管理協(xié)議”,對于理解 Kafka 的架構(gòu)設(shè)計是很有幫助的。
標題名稱:Kafka的三種客戶端線程模型和一個小驚喜
URL鏈接:http://jinyejixie.com/article32/jopssc.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站收錄、關(guān)鍵詞優(yōu)化、網(wǎng)站設(shè)計公司、定制開發(fā)、網(wǎng)站內(nèi)鏈、營銷型網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時需注明來源: 創(chuàng)新互聯(lián)