Apache Kafka 核心元件和流程-控制器-設計-原理(入門教程輕鬆學)
本入門教程,涵蓋Kafka核心內容,通過例項和大量圖表,幫助學習者理解,任何問題歡迎留言。
目錄:
通過前幾章的學習,我們已經從巨集觀層面瞭解了kafka的設計理念。包括kafka叢集的組成、訊息的主題、主題的分割槽、分割槽的副本等內容。接下來我們會繼續深入,瞭解kafka的主要元件以及核心的流程,最後還會介紹kafka的訊息是如何儲存的。此章非常重要,通過本章和上一章的學習,你已經能夠掌握kafka 80%的核心內容。當然隨著學習的深入,難度也會越來越大,有任何問題歡迎留言或者私信。
Kafka主要的元件如下:
控制器
協調器
日誌管理器
副本管理器
我們將會逐個進行講解,講解過長還將保持前面章節的特點,多用有形的圖表幫助讀者理解。
本篇部落格先講解控制器部分。其它元件再逐步發出
1、控制器
在前一章的學習中,我們已經知道Kafka的叢集由n個的broker所組成,每個broker就是一個kafka的例項或者稱之為kafka的服務。其實控制器也是一個broker,控制器也叫leader broker。
他除了具有一般broker的功能外,還負責分割槽leader的選取,也就是負責選舉partition的leader replica。
控制器是kafka核心中的核心,需要重點學習和理解。
控制器選舉
kafka每個broker啟動的時候,都會例項化一個KafkaController,並將broker的id註冊到zookeeper,這在第二章中已經通過例子做過講解。叢集在啟動過程中,通過選舉機制選舉出其中一個broker作為leader,也就是前面所說的控制器。
包括叢集啟動在內,有三種情況觸發控制器選舉:
1、叢集啟動
2、控制器所在代理髮生故障
3、zookeeper心跳感知,控制器與自己的session過期
按照慣例,先看圖。我們根據下圖來講解叢集啟動時,控制器選舉過程。
假設此叢集有三個broker,同時啟動。
(一)3個broker從zookeeper獲取/controller臨時節點資訊。/controller儲存的是選舉出來的leader資訊。此舉是為了確認是否已經存在leader。
(二)如果還沒有選舉出leader,那麼此節點是不存在的,返回-1。如果返回的不是-1,而是leader的json資料,那麼說明已經有leader存在,選舉結束。
(三)三個broker發現返回-1,瞭解到目前沒有leader,於是均會觸發向臨時節點/controller寫入自己的資訊。最先寫入的就會成為leader。
(四)假設broker 0的速度最快,他先寫入了/controller節點,那麼他就成為了leader。而broker1、broker2很不幸,因為晚了一步,他們在寫/controller的過程中會丟擲ZkNodeExistsException,也就是zk告訴他們,此節點已經存在了。
經過以上四步,broker 0成功寫入/controller節點,其它broker寫入失敗了,所以broker 0成功當選leader。
此外zk中還有controller_epoch節點,儲存了leader的變更次數,初始值為0,以後leader每變一次,該值+1。所有向控制器發起的請求,都會攜帶此值。如果控制器和自己記憶體中比較,請求值小,說明kafka叢集已經發生了新的選舉,此請求過期,此請求無效。如果請求值大於控制器記憶體的值,說明已經有新的控制器當選了,自己已經退位,請求無效。kafka通過controller_epoch保證叢集控制器的唯一性及操作的一致性。
由此可見,Kafka的控制器思想就是看誰先爭搶到/controller節點寫入自身資訊。
控制器初始化
控制器的初始化,其實是初始化控制器所用到的元件及監聽器,準備元資料。
前面提到過每個broker都會例項化並啟動一個KafkaController。KafkaController和他的元件關係,以及各個元件的介紹如下圖:
圖中箭頭為元件層級關係,元件下面還會再初始化其他元件。可見控制器內部還是有些複雜的,主要有以下元件:
1、ControllerContext,此物件儲存了控制器工作需要的所有上下文資訊,包括存活的代理、所有主題及分割槽分配方案、每個分割槽的AR、leader、ISR等資訊。
2、一系列的listener,通過對zookeeper的監聽,觸發相應的操作,黃色的框的均為listener
3、分割槽和副本狀態機,管理分割槽和副本。
4、當前代理選舉器ZookeeperLeaderElector,此選舉器有上位和退位的相關回調方法。
5、分割槽leader選舉器,PartitionLeaderSelector
6、主題刪除管理器,TopicDeletetionManager
7、leader向broker批量通訊的ControllerBrokerRequestBatch。快取狀態機處理後產生的request,然後統一發送出去。
8、控制器平衡操作的KafkaScheduler,僅在broker作為leader時有效。
圖片是我根據資料所總結,個人認為對於理解kafkaController的全貌很有幫助。本章節後面講到相應元件和流程時,還需要反覆回來理解此圖,思考元件所處的位置,對整體的作用。
故障轉移
故障轉移其實就是leader所在broker發生故障,leader轉移為其他的broker。轉移的過程就是重新選舉leader的過程。
重新選舉leader後,需要為該broker註冊相應許可權,呼叫的是ZookeeperLeaderElector的onControllerFailover()方法。在這個方法中初始化和啟動了一系列的元件來完成leader的各種操作。具體如下,其實和控制器初始化有很大的相似度。
1、註冊分割槽管理的相關監聽器
監聽名稱 | 監聽zookeeper節點 | 作用 |
PartitionsReassignedListener | /admin/reassign_partitions | 節點變化將會引發分割槽重分配 |
IsrChangeNotificationListener | /isr_change_notification | 處理分割槽的ISR發生變化引發的操作 |
PreferredReplicaElectionListener | /admin/preferred_replica_election | 將優先副本選舉為leader副本 |
2、註冊主題管理的相關監聽
監聽名稱 | 監聽zookeeper節點 | 作用 |
TopicChangeListener | /brokers/topics | 監聽主題發生變化時進行相應操作 |
DeleteTopicsListener | /admin/delete_topics | 完成伺服器端刪除主題的相應操作。否則客戶端刪除主題僅僅是表示刪除 |
3、註冊代理變化監聽器
監聽名稱 | 監聽zookeeper節點 | 作用 |
BrokerChangeListener | /brokers/ids | 代理髮生增減的時候進行相應的處理 |
4、重新初始化ControllerContext,
5、啟動控制器和其他代理之間通訊的ControllerChannelManager
6、建立用於刪除主題的TopicDeletionManager物件,並啟動。
7、啟動分割槽狀態機和副本狀態機
8、輪詢每個主題,新增監聽分割槽變化的PartitionModificationsListener
9、如果設定了分割槽平衡定時操作,那麼建立分割槽平衡的定時任務,預設300秒檢查並執行。
除了這些元件的啟動外,onControllerFailover方法中還做了如下操作:
1、/controller_epoch值+1,並且更新到ControllerContext
2、檢查是否出發分割槽重分配,並做相關操作
3、檢查需要將優先副本選為leader,並做相關操作
4、向kafka叢集所有代理髮送更新元資料的請求。
下面來看代理下線的方法onControllerResignation
1、該方法中登出了控制器的許可權。取消在zookeeper中對於分割槽、副本感知的相應監聽器的監聽。
2、關閉啟動的各個元件
3、最後把ControllerContext中記錄控制器版本的數值清零,並設定當前broker為RunnignAsBroker,變為普通的broker。
通過對控制器啟動過程的學習,我們應該已經對kafka工作的原理有了瞭解,核心是監聽zookeeper的相關節點,節點變化時觸發相應的操作。其它的處理流程都是相類似的。本篇教程接下來做簡要介紹,想要了解詳情的,可以先找其它資料。我後續也會再補充更為詳細的教程。
代理上下線
有新的broker加入叢集時,稱為代理上線。反之,當broker關閉,推出叢集時,稱為代理下線。
代理上線:
1、新代理啟動時向/brokers/ids寫資料
2、BrokerChangeListener監聽到變化。對新上線節點呼叫controllerChannelManager.addBroker(),完成新上線代理網路層初始化
3、呼叫KafkaController.onBrokerStartup()處理
3.1通過向所有代理髮送UpdateMetadataRequest,告訴所有代理有新代理加入
3.2根據分配給新上線節點的副本集合,對副本狀態做變遷。對分割槽也進行處理。
3.3觸發一次leader選舉,確認新加入的是否為分割槽leader
3.4輪詢分配給新broker的副本,呼叫KafkaController.onPartitionReassignment(),執行分割槽副本分配
3.5恢復因新代理上線暫停的刪除主題操作執行緒
代理下線:
1、查詢下線節點集合
2、輪詢下線節點,呼叫controllerChannelManager.removeBroker(),關閉每個下線節點網路連線。清空下線節點訊息佇列,關閉下線節點request請求
3、輪詢下線節點,呼叫KafkaController.onBrokerFailure處理
3.1處理leader副本在下線節點上上的分割槽,重新選出leader副本,傳送updateMetadataRequest請求。
3.2處理下線節點上的副本集合,做下線處理,從ISR集合中刪除,不再同步,傳送updateMetadataRequest請求。
4、向叢集全部存活代理髮送updateMetadataRequest請求
主題管理
通過分割槽狀態機及副本狀態機來進行主題管理
1、建立主題
/brokers/topics下建立主題對應子節點
TopicChangeListener監聽此節點
變化時獲取重入鎖ReentrantLock,呼叫handleChildChange方法進行處理。
通過對比zookeeper中/brokers/topics儲存的主題集合及控制器的ControllerContext中快取的主題集合的差集,得到新增的主題。反過來求差集,得到刪除的主題。
接下來遍歷新增的主題集合,進行主題操作的實質性操作。之前僅僅是在zookeeper中添加了主題。新增主題涉及的操作有分割槽、副本狀態的轉化、分割槽leader的分配、分割槽儲存日誌的建立等。
2、刪除主題
/admin/delete_topics建立刪除主題的子節點
DeleteTopicsListener監聽此節點,
變化時獲取重入鎖ReentrantLock,進行處理
具體的刪除邏輯再次就不再詳述。
分割槽管理
1、分割槽自動平衡
onControllerFailover方法中啟動分割槽自動平衡任務。定時檢查是否失去平衡。
自動平衡的操作就是把優先副本選為分割槽leader,AR中第一個副本為優先副本。
先查出所有可用副本,以分割槽AR頭節點分組。
輪詢代理節點,判斷分割槽不平衡率是否超過10%(leader為非優先副本的分割槽/該代理分割槽總數),則呼叫onPreferredReplicaElection(),讓優先副本成為leader。達到自動平衡。
分割槽平衡操作的流程已經在第三章做了很詳細的講解,此處不再重複,可以參考kafka核心概念。
2、分割槽重分配
當zk節點/admin/reassign_partitions變化時,觸發分割槽重分配操作。該節點儲存分割槽重分配的方案。
通過計算主題分割槽原AR(OAR)和重新分配後的AR(RAR),分別做相應處理:
1、OAR+RAR:更新到該主題分割槽AR,並通知副本節點同步。leader_epoch+1
2、RAR-OAR:副本設為NewReplica。
3、(OAR+RAR)- RAR:需要下線的副本,做下線操作
具體流程不再詳述
小結:關於控制器的相關知識點就先講到這裡,控制器初始化中的那張圖需要充分去理解,理解了此圖,對控制器內部的構造,以及控制器要做什麼事情、如何做的,就已經掌握了。另外考慮本教程定位為入門輕鬆學,所以具體的流程沒有展開來講,以後我會再寫相應的主題文章來說明。
相關推薦
Apache Kafka 核心元件和流程-控制器-設計-原理(入門教程輕鬆學)
本入門教程,涵蓋Kafka核心內容,通過例項和大量圖表,幫助學習者理解,任何問題歡迎留言。 目錄: 通過前幾章的學習,我們已經從巨集觀層面瞭解了kafka的設計理念。包括kafka叢集的組成、訊息的主題、主題的分割槽、分割槽的
Apache Kafka核心元件和流程-協調器(消費者和組協調器)-設計-原理(入門教程輕鬆學)
作者:稀有氣體 來源:CSDN 原文:https://blog.csdn.net/liyiming2017/article/details/82805479 版權宣告:本文為博主原創文章,轉載請附上博文連結! 本入門教程,涵蓋Kafka核心內容,通過例項和大量圖表,幫助學習
Apache Kafka 核心元件和流程-日誌管理器-設計-原理(入門教程輕鬆學)
本入門教程,涵蓋Kafka核心內容,通過例項和大量圖表,幫助學習者理解,任何問題歡迎留言。 目錄: 上一節介紹了協調器。協調器主要負責消費者和kafka叢集間的協調。那麼消費者消費時,如何定位訊息呢?訊息是如何儲存呢?本節將為
Apache Kafka-核心元件和流程-副本管理器-設計-原理(入門教程輕鬆學)
本入門教程,涵蓋Kafka核心內容,通過例項和大量圖表,幫助學習者理解,任何問題歡迎留言。 目錄: 本章簡單介紹了副本管理器,副本管理器負責分割槽及其副本的管理。副本管理器具體的工作流程可以參考牟大恩所著的《Kafka入門與實
Apache Kafka入門教程輕鬆學-第四章 Kafka核心元件和流程-設計-原理(一)控制器
本入門教程,涵蓋Kafka核心內容,通過例項和大量圖表,幫助學習者理解,任何問題歡迎留言。 目錄: 通過前幾章的學習,我們已經從巨集觀層面瞭解了kafka的設計理念。包括kafka叢集的組成、訊息的主題、主題的分割槽、分割槽的副本等內容。接下來我們會繼續深入,瞭解kafk
Apache Kafka入門教程輕鬆學-第四章 Kafka核心元件和流程-設計-原理(二)協調器(消費者和組協調器)
本入門教程,涵蓋Kafka核心內容,通過例項和大量圖表,幫助學習者理解,任何問題歡迎留言。 目錄: 上一節介紹了kafka工作的核心元件--控制器。本節將介紹消費者密切相關的元件--協調器。它負責消費者的出入組工作。大家可以回想一下kafka核心概念中關於吃蘋果的場景,如
Apache Kafka入門教程輕鬆學-第四章 Kafka核心元件和流程-設計-原理(四)副本管理器
本入門教程,涵蓋Kafka核心內容,通過例項和大量圖表,幫助學習者理解,任何問題歡迎留言。 目錄: 本章簡單介紹了副本管理器,副本管理器負責分割槽及其副本的管理。副本管理器具體的工作流程可以參考牟大恩所著的《Kafka入門與實踐》。 副本管理器 副本機制使得kafka
Apache Kafka入門教程輕鬆學- Kafka核心概念
本入門教程,涵蓋Kafka核心內容,通過例項和大量圖表,幫助學習者理解,任何問題歡迎留言。 目錄: 本章是學習kafka的核心章節,涵蓋內容比較多,在理解上有一定的難度,需要反覆閱讀理解,才能參透Kafka的設計思想。 1、Kafka叢集結構 在第一章我給出過一個訊息
Linux核心移植和根檔案系統製作(詳細步驟精講)
start_kernel是所有 Linux 平臺進入系統核心初始化後的入口函式,它主要完成剩餘的與硬體平臺相關的初始化工作,在進行一系列與核心相關的初始化後,呼叫第一個使用者程序-init 程序並等待使用者程序的執行,這樣整個 Linux 核心便啟動完畢。該函式所做的具體工作有:呼叫 setup_arch
Linux核心編譯和grub安裝注意事項(修改預設啟動項)
一般的過程不多說。 下載核心原始碼,make menuconfig , make , make modules_install, make install等一系列。 要注意的事情: 1.安裝模組時,要用特殊引數,否則編譯出來的initrd.img特別大有300M,而
史上最強Dubbo面試26題和答案:核心元件+服務治理+架構設計等
開發十年,就只剩下這套架構體系了! >>>
初始MyBatis框架(四大核心元件和配置檔案)
一、概述 MyBatis 本是apache的一個開源專案iBatis, 2010年這個專案由apache software foundation 遷移到了google code,並且改名為MyBatis 。2013年11月遷移到Github。 MyBatis 是一款優秀的持久層框
Kafka架構、Kafka核心元件、Kafka工作原理、Kafka應用場景
什麼是訊息系統? 訊息系統負責將資料從一個應用程式傳輸到另一個應用程式,因此應用程式可以專注於資料,但不擔心如何共享它。 分散式訊息傳遞基於可靠訊息佇列的概念。 訊息在客戶端應用程式和訊息傳遞系統之間非同步排隊。 有兩種型別的訊
Facebook開源Linux核心元件和工具:BPF、Btrfs、Netconsd、Cgroup2、PSI、Oomd
內容摘要: 作者:Tejun Heo(Facebook的軟體工程師)和Thomas Connally。 Facebook工程文化的一個組成部分始終是我們的開發團隊致力於開發開源解決方案,以解決實際的生產問題,並應對現代大規模雲端計算的重大挑戰。今天,我們宣佈了一套解決重要
分散式訊息中介軟體(六)——Kafka核心元件詳解
一、Kafka釋出訂閱訊息系統基礎 Kafka 是分散式釋出-訂閱訊息系統。它最初由 LinkedIn 公司開發,使用 Scala語言編寫,之後成為 Apache 頂級專案框架。Kafka
Spring Security詳解(一)認證之核心元件和服務
一直以來都特別喜歡Spring的全家桶系列,也一直想寫關於Spring Security的系列文章,接觸security從最初的Guide開始入手,到專案中的原始碼閱讀,最近又沉下心來看了幾遍文件,打算嘗試一下,把我的理解都記錄下來,寫一個較為完整的系列文章。
初識MyBatis框架(四大核心元件和配置檔案)
一、概述 MyBatis 本是apache的一個開源專案iBatis, 2010年這個專案由apache software foundation 遷移到了google code,並且改名為MyBatis 。2013年11月遷移到Github。 MyBatis 是
MyBatis的核心元件和生命週期
1 核心元件:(1)、SqlSessionFactoryBuilder(構造器):它會根據配置或者程式碼來生成SqlSessionFactory,採用的是分佈構建的Builder模式。(2)、SqlSe
微服務核心元件 Zuul 閘道器原理剖析 | 併發程式設計網
一、前言 Zuul 閘道器是具體核心業務服務的看門神,相比具體實現業務的系統服務來說它是一個邊緣服務,主要提供動態路由,監控,彈性,安全性等功能。在分散式的微服務系統中,系統被拆為了多套系統,通過zuul閘道器來對使用者的請求進行路由,轉發到具體的後臺服務系統中。 本 Chat 主要內容如下:
activiti入門和流程的執行過程(附程式碼)
1.定義bpmn檔案,這個檔案裡是用來定義流程的 2.釋出流程 釋出流程,流程的key值相同的情況下每次釋出一次,這個流程在資料庫的版本會+1 3.檢視流程定義 列印的資訊 可以看到,我剛才定義的流程已經更新了,現在是版本2了 4.建立流程例項