您好,登錄后才能下訂單哦!
本篇文章給大家分享的是有關怎樣解析Kafka架構,小編覺得挺實用的,因此分享給大家學習,希望大家閱讀完這篇文章后可以有所收獲,話不多說,跟著小編一起來看看吧。
Kafka是一個開源的、分布式的、可分區的、可復制的基于日志提交的發布訂閱消息系統。它具備以下特點:
1. 消息持久化: 為了從大數據中獲取有價值的信息,任何信息的丟失都是負擔不起的。Kafka使用了O(1)的磁盤結構設計,這樣做即便是在要存儲大體積的數據時也是可以提供穩定的性能。使用Kafka時,message會被存儲并且會被復制以防止數據丟失。
2. 高吞吐量: 設計是工作在普通的硬件設施上多個客戶端能夠每秒處理幾百兆的數據量。
3. 分布式: Kafka Broker的中心化集群支持消息分區,而consumer采用分布式進行消費。
4. 多種Client支持: Kafka很容易與其它平臺進行支持,例如:Java、.NET、PHP、Ruby、Python。
5. 實時: 消息由producer產生后立即對consumer可見。這個特性對于基于事件的系統是很關鍵的。
下面就來對Kafka架構做一個簡單的說明:
Kafka各組件說明
Topic 與 Broker
partition log
partition distribution
Broker
Topic
Producer
Consumer
Kafka 提供的保障
架構圖
每個kafka server稱為一個Broker,多個borker組成kafka cluster。
一個機器上可以部署一個或者多個Broker,這多個Broker連接到相同的ZooKeeper就組成了Kafka集群。
Topic
Kafka是一個發布訂閱消息系統,它的邏輯結構如下:
Topic 就是消息類別名,一個topic中通常放置一類消息。每個topic都有一個或者多個訂閱者,也就是消息的消費者consumer。
Producer將消息推送到topic,由訂閱該topic的consumer從topic中拉取消息。
一個Broker上可以創建一個或者多個Topic。同一個topic可以在同一集群下的多個Broker中分布。
Kafka會為每個topic維護了多個分區(partition),每個分區會映射到一個邏輯的日志(log)文件:
每當一個message被發布到一個topic上的一個partition,broker應會將該message追加到這個邏輯log文件的最后一個segment上。這些segments 會被flush到磁盤上。Flush時可以按照時間來進行,也可以按照message 數來執行。
每個partition都是一個有序的、不可變的結構化的提交日志記錄的序列。在每個partition中每一條日志記錄都會被分配一個序號——通常稱為offset,offset在partition內是唯一的。論點邏輯文件會被化分為多個文件segment(每個segment的大小一樣的)。
Broker集群將會保留所有已發布的message records,不管這些消息是否已被消費。保留時間依賴于一個可配的保留周期。例如:如果設置了保留策略是2day,那么每一條消息發布兩天內是被保留的,在這個2day的保留時間內,消息是可以被消費的。過期后不再保留。
Partition distribution
日志分區是分布式的存在于一個kafka集群的多個broker上。每個partition會被復制多份存在于不同的broker上。這樣做是為了容災。具體會復制幾份,會復制到哪些broker上,都是可以配置的。經過相關的復制策略后,每個topic在每個broker上會駐留一到多個partition。如圖:
對于同一個partition,它所在任何一個broker,都有能扮演兩種角色:leader、follower。
看上面的例子。紅色的代表是一個leader。
對于topic1的4個partition:
Part 1的leader是broker1,followers是broker2。
Part2的leader是broker2,followers是broker1。
Part3的leader是broker3,followers是broker1。
Part4的leader是broker4,followers是broker2。
對于topic2的3個partition:
Part1的leader是broker1,followers是broker2。
Part2的leader是broker2,followers是broker3。
Part3的leader是broker3,followers是broker4。
對于topic2的4個partition:
Part 1的leader是broker4,followers是broker1。
Part2的leader是broker2,followers是broker1。
Part3的leader是broker3,followers是broker1。
Part4的leader是broker1,followers是broker2。
下面是一個真實的例子:
圖中的partition 0 的leader是broker 2,它有3個replicas:2,1,3。
In-Sync Replica:在同步中,也就是有哪些broker正處理同步中。partition 0的ISR是2,1,3,說明了3個replica都是正常狀態。如果有一個broker down,那么它就不會在ISR中出現。
之后把broker1停止后:
每個partition的Leader的用于處理到該partition的讀寫請求的。
每個partition的followers是用于異步的從它的leader中復制數據的。
Kafka會動態維護一個與Leader保持一致的同步副本(in-sync replicas (ISR))集合,并且會將最新的同步副本(ISR )集合持久化到zookeeper。如果leader出現問題了,就會從該partition的followers中選舉一個作為新的leader。
所以呢,在一個kafka集群中,每個broker通常會扮演兩個角色:在一個partition中扮演leader,在其它的partition中扮演followers。Leader是最繁忙的,要處理讀寫請求。這樣將leader均分到不同的broker上,目的自然是要確保負載均衡。
Producer
Producer作為消息的生產者,在生產完消息后需要將消息投送到指定的目的地(某個topic的某個partition)。Producer可以根據指定選擇partition的算法或者是隨機方式來選擇發布消息到哪個partition。
Consumer
在Kafka中,同樣有consumer group的概念,它是邏輯上將一些consumer分組。因為每個kafka consumer是一個進程。所以一個consumer group中的consumers將可能是由分布在不同機器上的不同的進程組成的。Topic中的每一條消息可以被多個consumer group消費,然而每個consumer group內只能有一個consumer來消費該消息。所以,如果想要一條消息被多個consumer消費,那么這些consumer就必須是在不同的consumer group中。所以也可以理解為consumer group才是topic在邏輯上的訂閱者。
每個consumer可以訂閱多個topic。
每個consumer會保留它讀取到某個partition的offset。而consumer 是通過zookeeper來保留offset的。
Kafka提供的保障
1、如果producer往特定的partition發送消息時,會按照先后順序存儲,也就是說如果發送順序是message1、message2、message3。那么這三個消息在partition log中的記錄的offset就是 message1_offset < message2_offset < message3_offset。
2、consumer也是有序的瀏覽log中的記錄。
3、如果一個topic指定了replication factor為N,那么就允許有N-1個Broker出錯。
架構圖
對上述各組件介紹后,現在就應該可以很容易的理解Kafka的架構圖:
以上就是怎樣解析Kafka架構,小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。