一文帶你搞懂 Kafka 的系統架構(深度好文,值得收藏)

来源:https://www.cnblogs.com/datadance/archive/2022/05/20/16292991.html
-Advertisement-
Play Games

Kafka 簡介 Kafka 是一種高吞吐、分散式、基於發佈和訂閱模型的消息系統,最初是由 LinkedIn 公司採用 Scala 和 java 開發的開源流處理軟體平臺,目前是 Apache 的開源項目。 Kafka 用於離線和線上消息的消費,將消息數據按順序保存在磁碟上,併在集群內以副本的形式存 ...


Kafka 簡介

Kafka 是一種高吞吐、分散式、基於發佈和訂閱模型的消息系統,最初是由 LinkedIn 公司採用 Scala 和 java 開發的開源流處理軟體平臺,目前是 Apache 的開源項目。

Kafka 用於離線和線上消息的消費,將消息數據按順序保存在磁碟上,併在集群內以副本的形式存儲以防止數據丟失。Kafka 可以依賴 ZooKeeper 進行集群管理,並且受到越來越多的分散式處理系統的青睞,比如 Storm、Spark、Flink 等都支持與 Kafka 集成,用於實時流式計算。

Kafka 開發者 Jay Kreps 提及關於 Kafka 名字的由來:
“ 因為 Kafka 系統的寫性能很強,所以找一個作家的名字來命名似乎是個好主意,大學期間我上了很多文學課,非常喜歡 Franz Kafka 這個作家,另外,這個名字聽上去也很酷~~ ”

消息隊列是乾什麼的?

學習 Kafka 不可避免地要認識下消息隊列,也就是我們常提到的 MQ(Message Queue),因為 Kafka 本質上也是一個消息隊列。

那麼消息隊列又是什麼呢?先來看一個比較官方的回答。

消息隊列是一種進程間通信或者同一個進程中不同線程間的通信方式,主要解決非同步處理、應用耦合、流量消峰等問題,實現高性能、高可用、可伸縮和最終一致性架構,是大型分散式系統不可缺少的中間件。

再說的直觀點,如下圖,系統 A 將消息發佈到 MQ,然後系統 B 再從 MQ 取消息。
在這裡插入圖片描述
那麼,為什麼系統 A 不直接發消息給系統 B ,中間還要隔一個 MQ 呢?這就要看下 MQ 的三個主要功能了。

1)非同步處理

消息隊列提供了非同步處理機制,因為很多時候用戶並不需要立即響應來處理消息,那麼通過這個機制就可以把所有消息放入 MQ 中。比如,某系統發來的數據中包含很多圖片信息,如果對其中的信息都進行保存處理,用戶一番操作下來可能會很久。採用非同步處理之後,系統會將所有數據存放在 MQ 中,用戶不需要立即處理,大大縮短了系統的響應時間。
在這裡插入圖片描述
2)應用解耦

消息隊列可以對系統間的依賴進行解耦,降低依賴系統變更帶來的影響。比如,用戶在下單後,訂單系統A需要通知系統B、系統C等做出響應的處理。傳統的做法,如下圖所示。
在這裡插入圖片描述
此時的系統A是強依賴系統B和系統C的,一旦系統B出現故障或者需要重新加入高耦合的系統D時,就必須要更改系統A的代碼。
在這裡插入圖片描述
如果經常出現這種依賴系統迭代的情況,那麼系統A就會很難維護,可以通過消息隊列對依賴系統進行解耦(如下圖),這樣系統A也無需關心其他系統的可用性。
在這裡插入圖片描述
3)流量削峰

流量削峰還有個形象的名字叫做削峰填谷,其實就是指當數據量激增時,能夠有效地隔離上下游業務,將上游突增的流量緩存起來,真正地填到谷中,以平滑的方式傳到下游系統,避免了流量的不規則衝擊。

比如,有個活動頁面平時也就 50qps,某一特殊時刻訪問量突然增多,能達到 1000qps,但是當前系統的處理能力最多為 100qps,這個時候可以通過消息隊列來進行削峰填谷,如下圖所示。
在這裡插入圖片描述
當然,Kafka 除了以上 MQ 這些功能之外,還提供了消息順序性保障、回溯消息、持久化存儲等功能,這個在後續文章中會詳細講解。

MQ 的兩種傳輸模式

消息在 MQ 中有兩種傳輸模型,分別是點對點(point to point)和發佈/訂閱(publish/subscribe)模型。

1)點對點模型

如圖所示,系統A發送的消息只能被系統B接收,其他的任何系統都不能獲取到系統A發送的消息。在日常生活中就像A撥通了B的電話,其他人是不可能接聽到的。
在這裡插入圖片描述

2)發佈/訂閱模型

與點對點模型的區別在於發佈/訂閱模型多了一個 topic 的概念,可以存在多個發佈者向相同主題發送消息,而訂閱者也可以存在多個,接收相同主題的消息。在日常生活中就像不同主題的報紙期刊,同時也有不同群體的讀者來訂閱。
在這裡插入圖片描述
那麼 Kafka 屬於哪種呢,事實上 Kafka 可以同時支持這兩種傳輸模型,這個後面會講。

Kafka 系統架構

終於到主角登場了,一個典型的Kafka 系統架構會包括 Producer、broker、Cosumer 等角色,以及一個 ZooKeeper 集群,先上個圖。
在這裡插入圖片描述

  • Producer:生產者,負責將客戶端生產的消息發送到 Kafka 中,可以支持消息的非同步發送和批量發送;
  • broker:服務代理節點,Kafka 集群中的一臺伺服器就是一個 broker,可以水平無限擴展,同一個 Topic 的消息可以分佈在多個 broker 中;
  • Consumer:消費者,通過連接到 Kafka 上來接收消息,用於相應的業務邏輯處理。
  • ZooKeeper:不廢話了~不認識它的可以翻下我前面發的文章,一文搞定 ZooKeeper;
  • Consumer Group:消費者組,指的是多個消費者共同組成一個組來消費一個 Topic 中的消息。

前面提到 Kafka 同時支持兩種消息傳輸模型,其中實現點對點模型的方式就是引入了 Consumer Group,目的主要是讓多個消費者同時消費,可以加速整個消費者端的吞吐量。

需要註意的是:一個 Topic 中的一個分區只能被同一個 Consumer Group 中的一個消費者消費,其他消費者不能進行消費。這裡的一個消費者,指的是運行消費者應用的進程,也可以是一個線程。

在整個 Kafka 集群中 Producer 將消息發送給 broker,然後 broker 再將接收到的消息存儲到磁碟中,然後 Consumer 再從 Broker 訂閱並消費消息。ZooKeeper 則是 Kafka 集群用來負責集群元數據的管理、控制器的選舉等操作的。

Kafka 中的重要概念

1)Topic 與 Partition

在 Kafka 中消息是以 Topic 為單位進行歸類的,Topic 在邏輯上可以被認為是一個 Queue,Producer 生產的每一條消息都必須指定一個 Topic,然後 Consumer 會根據訂閱的 Topic 到對應的 broker 上去拉取消息。

為了提升整個集群的吞吐量,Topic 在物理上還可以細分多個分區,一個分區在磁碟上對應一個文件夾。由於一個分區只屬於一個主題,很多時候也會被叫做主題分區(Topic-Partition)。

2)Leader 和 Follower

一個分區會有多個副本,副本之間是一主(Leader)多從(Follower)的關係,Leader 對外提供服務,這裡的對外指的是與客戶端程式進行交互,而 Follower 只是被動地同步 Leader 而已,不能與外界進行交互。

當然了,你可能知道在很多其他系統中 Follower 是可以對外提供服務的,比如 MySQL 的從庫是可以處理讀操作的,但是在 Kafka 中 Follower 只負責消息同步,不會對外提供服務。

一個有意思的事情是現在已經不提倡使用Master-Slave來指代這種主從關係了,畢竟Slave有奴隸的意思,在美國這種嚴禁種族歧視的國度,這種表述有點政治不正確了,所以目前大部分的系統都改成Leader-Follower了。

Kafka 多副本機制

Kafka 為分區引入了多副本機制,同一分區的不同副本中保存的信息是相同的,通過多副本機制實現了故障的自動轉移,當集群中某個 broker 失效時仍然能保證服務可用,可以提升容災能力。

如圖所示,Kafka 集群中有4個 broker,某個 Topic 有三個分區,假設副本因數也有設置為3,那麼每個分區就會有一個 Leader 和兩個 Follower 副本。

在這裡插入圖片描述
副本處於不同 broker 中,生產者與消費者只和 Leader 副本進行交互,而 Follower 副本只負責消息的同步。當 Leader 副本出現故障時,會從 Follower 副本中重新選舉新的 Leader 副本對外提供服務。

接下來我們來瞭解 Kafka 多副本機制中的一些重要術語。

  • AR(Assigned Replicas):一個分區中的所有副本統稱為 AR;
  • ISR(In-Sync Replicas):Leader 副本和所有保持一定程度同步的 Follower 副本(包括 Leader 本身)組成 ISR;
  • OSR(Out-of-Sync Raplicas):與 ISR 相反,沒有與 Leader 副本保持一定程度同步的所有Follower 副本組成OSR;

首先,生產者會將消息發送給 Leader 副本,然後 Follower 副本才能從 Leader 中拉取消息進行同步,在同一時刻,所有副本中的消息不完全相同,也就是說同步期間,Follower 相對於 Leader 而言會有一定程度上的滯後,當然這個滯後程度是可以通過參數來配置的。

那麼,我們就可以釐清了它們三者的關係:AR = ISR + OSR。

Leader 負責維護和跟蹤 ISR 集合中所有 Follower 副本的滯後狀態,當 Follower 出現滯後太多或者失效時,Leader 將會把它從 ISR 集合中剔除。

當然,如果 OSR 集合中有 Follower 同步範圍追上了 Leader,那麼 Leader 也會把它從 OSR 集合中轉移至 ISR 集合。

一般情況下,當 Leader 發送故障或失效時,只有 ISR 集合中的 Follower 才有資格被選舉為新的 Leader,而 OSR 集合中的 Follower 則沒有這個機會(不過可以修改參數配置來改變)。


 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 知識回顧 上一篇介紹了Spring中三級緩存的singletonObjects、earlySingletonObjects、singletonFactories,Spring在處理迴圈依賴時在實例化後屬性填充前將一個lambda表達式放在了三級緩存中,後續在獲取時進行了判斷,如果不需要進行對象代理, ...
  • 1. Netty源碼研究筆記(2)——Bootstrap系列 顧名思義,Bootstrap是netty提供給使用者的腳手架,類似於Spring的ApplicationContext,通過Bootstrap我們使用一些自定義選項,將相關的組件打包起來,從而快速的啟動伺服器、客戶端。 Bootstrap ...
  • ZooKeeper知識點總結 一、ZooKeeper 的工作機制 二、ZooKeeper 中的 ZAB 協議 三、數據模型與監聽器 四、ZooKeeper 的選舉機制和流程 本文將以如下內容為主線講解ZooKeeper中的學習重點,包括 ZooKeeper 中的角色、ZAB協議、數據模型、選舉機制、 ...
  • 現在驗證碼登錄已經成為很多應用的主流登錄方式,但是對於OAuth2授權來說,手機號驗證碼處理用戶認證就非常繁瑣,很多同學卻不知道怎麼接入。 認真研究胖哥Spring Security OAuth2專欄的都會知道一個事,OAuth2其實不管資源擁有者是如何認證的,只要資源擁有者在授權的環節中認證了就可 ...
  • 來源:csdn.net/xiaojin21cen/article/details/78587425 ZeroC ICE的Java版,Netty2作者的後續之作Apache MINA,Crmky的Cindy之外,還有個超簡單的QuickServer,讓你專心編寫自己的業務代碼,不用編寫一行TCP代碼。 ...
  • 1.創建線程池相關參數 線程池的創建要用ThreadPoolExecutor類的構造方法自定義創建,禁止用Executors的靜態方法創建線程池,防止記憶體溢出和創建過多線程消耗資源。 corePoolSize: 線程池核心線程數量,不會自動銷毀,除非設置了參數allowCoreThreadTimeO ...
  • 我們在上一篇博客中介紹了Linux系統Shell命令行下可執行程式應該遵守的傳參規範(包括了各種選項及其參數)。Python命令行程式做為其中一種,其傳參中也包括了位置參數(positional和可選參數(optional)。Python程式中我們解析在命令行中提供的各種選項(選項保存在sys.ar... ...
  • 1. Netty源碼研究筆記(1)——開篇 1.1. Netty介紹 Netty是一個老牌的高性能網路框架。在眾多開源框架中都有它的身影,比如:grpc、dubbo、seata等。 裡面有著非常多值得學的東西: I/O模型 記憶體管理 各種網路協議的實現:http、redis、websocket等等 ...
一周排行
    -Advertisement-
    Play Games
  • 一:背景 準備開個系列來聊一下 PerfView 這款工具,熟悉我的朋友都知道我喜歡用 WinDbg,這東西雖然很牛,但也不是萬能的,也有一些場景他解決不了或者很難解決,這時候藉助一些其他的工具來輔助,是一個很不錯的主意。 很多朋友喜歡在項目中以記錄日誌的方式來監控項目的流轉情況,其實 CoreCL ...
  • 本來閑來無事,準備看看Dapper擴展的源碼學習學習其中的編程思想,同時整理一下自己代碼的單元測試,為以後的進一步改進打下基礎。 突然就發現問題了,源碼也不看了,開始改代碼,改了好久。 測試Dapper.LiteSql數據批量插入的時候,耗時20秒,感覺不正常,於是我測試了非Dapper版的Lite ...
  • 需求如下,在DEV框架項目中,需要在表格中增加一列顯示圖片,並且能編輯該列圖片,然後進行保存等操作,最終效果如下 這裡使用的是PictureEdit控制項來實現,打開DEV GridControl設計器,在ColumnEdit選擇PictureEdit: 綁定圖片代碼如下: DataTable dtO ...
  • 前兩天微軟偷偷更新了Visual Studio 2022 正式版版本 17.3 發佈,發佈摘要: MAUI 工作負荷 GA 生成 MAUI/Blazor CSS 熱重載支持 現在,你將能夠使用我們的新增功能在 Visual Studio 中使用每個更新試用一系列新功能。 選擇每個功能以瞭解有關特定功 ...
  • 航天和軍工領域的數字化轉型和建設正在積極推進,在與航天二院、航天三院、航天六院、航天九院、無線電廠、兵工廠等單位交流的過程中,用戶更聚焦試驗和生產過程中的痛點,迫切需要解決軟體平臺統一監測和控制設備及軟體與設備協同的問題。 ...
  • .NET 項目預設情況下 日誌是使用的 ILogger 介面,預設提供一下四種日誌記錄程式: 控制台 調試 EventSource EventLog 這四種記錄程式都是預設包含在 .NET 運行時庫中。關於這四種記錄程式的詳細介紹可以直接查看微軟的官方文檔 https://docs.microsof ...
  • 一:背景 上一篇我們聊到瞭如何去找 熱點函數,這一篇我們來看下當你的程式出現了 非托管記憶體泄漏 時如何去尋找可疑的代碼源頭,其實思路很簡單,就是在 HeapAlloc 或者 VirtualAlloc 時做 Hook 攔截,記錄它的調用棧以及分配的記憶體量, PerfView 會將這個 分配量 做成一個 ...
  • 背景 在 CI/CD 流程當中,測試是 CI 中很重要的部分。跟開發人員關係最大的就是單元測試,單元測試編寫完成之後,我們可以使用 IDE 或者 dot cover 等工具獲得單元測試對於業務代碼的覆蓋率。不過我們需要一個獨立的 CLI 工具,這樣我們才能夠在 Jenkins 的 CI 流程集成。 ...
  • 一、應用場景 大家在使用Mybatis進行開發的時候,經常會遇到一種情況:按照月份month將數據放在不同的表裡面,查詢數據的時候需要跟不同的月份month去查詢不同的表。 但是我們都知道,Mybatis是ORM持久層框架,即:實體關係映射,實體Object與資料庫表之間是存在一一對應的映射關係。比 ...
  • 我國目前並未出台專門針對網路爬蟲技術的法律規範,但在司法實踐中,相關判決已屢見不鮮,K 哥特設了“K哥爬蟲普法”專欄,本欄目通過對真實案例的分析,旨在提高廣大爬蟲工程師的法律意識,知曉如何合法合規利用爬蟲技術,警鐘長鳴,做一個守法、護法、有原則的技術人員。 案情介紹 深圳市快鴿互聯網科技有限公司 2 ...