1.概述
對於Kafka的學習，在研究其系統模組時，有些核心元件是指的我們去了解。今天給大家來剖析一下Kafka的一些核心元件，讓大家能夠更好的理解Kafka的運作流程。
2.內容
Kafka系統設計的非常優秀，它的核心元件由生產者、消費者、主題、代理節點、以及Zookeeper組成。這些核心元件彼此獨立、卻又相互存在一定的聯絡來支援Kafka系統正常運作。
2.1 核心元件術語
2.1.1 生產者
生產者即訊息資料產生的來源頭，通常情況下，將原始資料（如資料庫、審計日誌、系統日誌）寫入到Kafka系統的應用程式稱之為生產者例項。
生產者的主要作用是傳送業務資料到Kafka系統，它在Kafka系統中承擔著“搬運工”的角色，負責將分佈在不同地方的原始資料，集中“搬運”到Kafka系統中進行儲存。
2.1.2 消費者
消費者即訊息資料流出的出口，通常情況下，讀取Kafka系統中業務資料的應用程式被稱為消費者例項。
消費者的主要作用是讀取Kafka系統中的業務資料，然後在消費者例項中經過邏輯處理後將結果寫到不同的及時查詢儲存介質中。例如，將經過處理後的結果分別寫入到分散式檔案系統（HDFS）、非關係型海量儲存資料庫（HBase）等。消費者在Kafka系統中承擔著資料分流的角色。
提示：
資料分流顧名思義就是將一份資料分別寫入到不同的地方。在大資料領域中，例如Kafka系統中集中儲存了業務資料，使用者通過消費者例項，讀取了Kafka系統中的業務資料，經過業務處理後，結果需要寫到不同的及時查詢儲存介質中。這個過程就是一個典型的資料分流過程。
2.1.3 Topic（主題）
主題即業務資料在Kafka系統中的分類集合，通常情況下，相同型別的業務資料會儲存在同一個主題下。 主題的主要作用是將不同的業務資料分類儲存，便於Kafka系統統一維護和管理業務資料。對比關係型資料庫，主題在Kafka系統中“扮演”的角色和關係型資料庫中表的角色很類似。
2.1.4 Broker（代理節點）
代理節點即Kafka系統中服務節點，通常情況下，Kafka系統中一臺伺服器主機被稱為Kafka系統的一個代理節點。
代理節點的主要作用是負責訊息資料的儲存、為客戶端提供服務、保證Kafka系統的正常執行等。代理節點是Kafka系統組建叢集的最小單位，一個Kafka叢集由一個代理節點或者多個代理節點組成。
2.1.5 Zookeeper
Zookeeper即Kafka叢集後設資料管理系統，由於Kafka系統是一個分散式訊息系統，由於分散式的原因，Kafka系統需要Zookeeper來協調管理服務。
Zookeeper在Kafka系統中主要作用是選舉主題分割槽Leader、協調各個代理節點服務、儲存Kafka後設資料資訊等。
在新版本Kafka系統中，Kafka系統對於新的消費者例項使用了Kafka內部的消費者組協調協議，減少了對Zookeeper的依賴。這時的Zookeeper對於Kafka系統來說，更像是一個小型的分散式後設資料儲存系統。
2.2 核心元件後設資料分佈
Kafka系統中，核心元件的後設資料資訊均儲存在Zookeeper系統。這些後設資料資訊具體包含控制器選舉次數、代理節點和主題、配置、管理員操作、控制器、以及老版本消費者例項。這些後設資料資訊在Zookeeper系統中的分佈，如下圖所示：
2.2.1 控制器選舉次數
Kafka系統中的控制器每進行一次選舉次數，都會在Zookeeper系統/controller_epoch節點下進行記錄。該值為一個數字，Kafka叢集中第一個代理節點（Broker）啟動時該值為1。
Kafka叢集中,如果遇到代理節點當機或者變更，那麼Kafka叢集會重新選舉新的控制器。每次控制器發生變化時，在Zookeeper系統/controller_epoch節點中的值就會加1。
2.2.2 Broker和Topic
在Zookeeper系統/brokers節點中儲存著Kafka代理節點和主題的後設資料資訊。
其中，Zookeeper系統/brokers/ids節點中儲存著代理節點的ID值。Zookeeper系統/brokers/topics節點中儲存著主題和分割槽的後設資料資訊。
2.2.3 配置
Kafka系統中修改主題屬性這類操作，會被儲存到Zookeeper系統/config節點，/config節點主要包含三個子節點，分別是：
- topic：儲存Kafka叢集主題的額外屬性，比如修改過主題的屬性操作；
- client：客戶端和主題配置被重寫，包含消費者應用和生產者應用；
- changes：配置修改通知。
2.2.4 管理員操作
在執行管理員操作時，比如刪除、分配等。在Zookeeper系統/admin節點會生成相應的子節點，內容如下：
- delete_topics：標記待刪除的主題名；
- reassign_partitions：重新分配分割槽操作；
- preferred_replica_election：恢復Leader分割槽平衡操作。
2.2.5 控制器
Kafka系統正常執行時，在Zookeeper系統/controller節點下會儲存一個Kafka代理節點的ID值，該ID值與Kafka代理節點ID相同，表示代理節點上存在控制器功能。
2.2.6 老版本消費者例項
在消費者例項中，如果使用kafka.tools.ConsoleConsumer介面去讀取Kafka主題資料，則會產生Zookeeper系統/consumers節點。
在Zookeeper系統/consumers節點中，存在若干個消費者組子節點，每個消費者組子節點下又會存在三個子子節點：
- 消費者執行緒ID（Zookeeper系統/consumers/ids）；
- 消費者產生的偏移量（Zookeeper系統/consumers/offsets）；
- 消費者執行緒和分割槽的對應關係（Zookeeper系統/consumers/owners）。
注意：
如果使用的是Kafka新版本消費者介面，則消費者例項產生的後設資料資訊不會儲存在Zookeeper系統/consumers節點中，而是儲存在Kafka系統的內部主題中。
3.分割槽儲存與過期資料刪除
- Broker：Kafka叢集組建的最小單位，訊息中介軟體的代理節點；
- Topic：用來區分不同的業務訊息，類似於資料庫中的表；
- Partition：Topic物理意義上的分組，一個Topic可以分為多個Partition，每個Partition是一個有序的佇列；
- Segment：每個Partition又可以分為多個Segment檔案；
- Offset：每個Partition都由一系列有序的、不可修改的訊息組成，這些訊息被持續追加到Partition中，Partition中的每條訊息記錄都有一個連續的序號，用來標識這條訊息的唯一性；
- Message：Kafka系統中，檔案儲存的最小儲存單位。
Kafka系統中的Message是以Topic為基本單位，不同的Topic之間是相互獨立、互不干擾的。每個Topic又可以分為若干個Partition，每個Partition用來儲存一部分的Message。
3.1 分割槽儲存
Kafka系統在建立主題時，它會規劃將分割槽分配到各個代理節點（Broker）。例如，現有3個代理節點，準備建立一個包含6個分割槽、3個副本的主題，那麼Kafka系統就會有18個分割槽副本，這18個分割槽副本能夠被分配到3個代理節點。
在Kafka系統中，一個主題（Topic）下包含多個不同的分割槽（Partition），每個分割槽為單獨的一個目錄，分割槽的命名規則為：主題名+有序序號，第一個分割槽的序號從正整數0開始，序號最大值等於分割槽總數減1。 主題的儲存路徑由“log.dirs”屬性決定，切換到代理節點中主題分割槽的儲存分佈，結果如圖所示：
每個分割槽相當於一個超大的檔案被均勻分配成若干個大小相等的片段（Segment），但是每個片段的訊息資料量不一定是相等的，正因為這種特性的存在，方面過期的片段資料能夠被快速的刪除。 片段檔案的生命週期由代理節點server.properties檔案中配置的引數決定，這樣快速刪除無用的資料，可以有效的提高磁碟利用率。
片段檔案由索引檔案和資料檔案組成，其中字尾為“.index”表示索引檔案，字尾為“.log”的表示資料檔案，檢視某一個分割槽的片段，輸出結果如下圖所示：
Kafka系統中的索引檔案並沒有給資料檔案中的每條訊息記錄都建立索引，而是採用了稀疏儲存的方式，每隔一定位元組的資料來建立一條索引。如下圖所示：
提示：
通過稀疏儲存索引的方式，避免了索引檔案佔用過多的磁碟空間。從而將索引檔案儲存在記憶體中，雖然沒有建立索引的Message不能一次性定位到所在的資料檔案上的位置，但是因為有稀疏索引的存在，會極大的縮小順序掃描的範圍。
3.2 訊息格式
對於普通日誌來說，一條記錄以“\n”結尾，或者通過其他特殊的分隔符來拆分，這樣就可以從檔案中拆分出一條條的記錄。但是這種方式對於文字來說比較適合，對Kafka系統來說，需要的是一種二進位制格式。 因此，Kafka系統使用了一種經典的訊息格式，在訊息前面固定長度的幾個位元組中記錄這條訊息的大小（單位為byte）。在Kafka系統訊息協議中，訊息的具體格式見程式碼如下：
Message => Crc MagicByte Attributes Key Value Crc => int32 MagicByte => int8 Attributes => int8 Timestamp => int64 Key => bytes Value => bytes
這些欄位含義如下所示：
4.清理過期資料
Kafka系統在清理過期的訊息資料時，提供了兩種清除策略。它們分別是：
- 基於時間和大小的刪除策略；
- 壓縮（Compact）清理策略。
這兩種策略通過屬性“log.cleanup.policy”來控制，可選值包含“delete”、“compact”，其預設值為“delete”。
1.刪除策略
按照時間來配置刪除策略，配置內容：
# 系統預設儲存7天 log.retention.hours=168
按照保留大小來刪除過期資料，配置內容：
# 系統預設沒有設定大小 log.retention.bytes=-1
另外，也可以同時配置時間和大小，來進行設定混合規則。一旦日誌大小超過閥值就清除分割槽中老的片段資料，或者分割槽中某個片段的的資料超過保留時間也會被清除。
2.壓縮策略
如果要使用壓縮策略清除過期日誌，需要顯示的指定屬性“log.cleanup.policy”的值為“compact”。壓縮清除，只能針對特定的主題應用，即寫的訊息資料都包含Key，合併相同Key的訊息資料，只留下最新的訊息資料。
5.總結
Kafka核心元件整體來說比較好理解，實際在編寫應用程式時，用到比較頻繁的就是生產者和消費者，因此，處理學會應用之外，我們還需要更近一步的來了解Kafka的核心元件。
6.結束語
這篇部落格就和大家分享到這裡，如果大家在研究學習的過程當中有什麼問題，可以加群進行討論或傳送郵件給我，我會盡我所能為您解答，與君共勉！
另外，博主出書了《Hadoop大資料探勘從入門到進階實戰》，喜歡的朋友或同學， 可以在公告欄那裡點選購買連結購買博主的書進行學習，在此感謝大家的支援。