在詳細介紹卡夫卡的架構和基本組成之前，我們需要了解壹些卡夫卡的核心概念。
生產者:消息的生產者，負責向Kafka集群發送消息；
消費者:消息的消費者，主動從Kafka集群拉取消息。
消費者群體:每個消費者都屬於壹個特定的消費者群體。創建新的消費者時，您需要指定相應的消費者組ID。
代理:Kafka集群中的服務實例，也稱為節點，每個Kafka集群包含壹個或多個代理(代理是服務器或節點)。
消息:通過Kafka集群傳輸的對象實體，存儲需要傳輸的信息。
主題:消息的類別，主要用於邏輯上區分消息。發送到Kafka cluster的每條消息都需要壹個指定的主題，消費者根據主題消費指定的消息。
分區:消息的分區。分區是壹個物理概念，相當於文件夾。Kafka會為每個主題的每個分區創建壹個文件夾，壹個主題消息會存儲在壹個或多個分區中。
Segment:壹個分區中有多個段文件段(分段存儲)，每個段分為兩部分，壹個. log文件和壹個。索引文件，其中。索引文件是壹個索引文件，主要用於快速查詢數據在。日誌文件；
。日誌文件:存儲消息的數據文件，在Kafka中稱為日誌文件。默認情況下，壹個分區下有n個以上的. log文件(分段存儲)。. log文件的默認值是1G，消息將不斷追加到。日誌文件。當。日誌文件超過1G，壹個新的。將自動創建日誌文件。
。索引文件:存儲索引數據。日誌文件，每個。索引文件有相應的。同名的日誌文件。
稍後，我們將更深入地介紹上面的壹些核心概念。介紹完Kafka的核心概念，我們再來看看Kafka提供的基本功能、組件和架構設計。
如上圖所示，Kafka主要包含四個主要的API組件:
1.生產者API
應用程序通過Producer API向Kafka集群發送壹個或多個主題消息。
2.消費者API
應用程序通過消費者API從Kafka集群訂閱壹個或多個主題消息，並處理在這些主題下收到的消息。
3.流API
通過使用Streams API作為流處理器，應用程序可以從壹個或多個主題獲得輸入流，並產生到壹個或多個主題的輸出流，這可以有效地將輸入流轉換為輸出流，並輸出到Kafka集群。
4.連接API
允許應用程序通過Connect API構建和運行可重用的生產者或消費者，並可以將kafka主題連接到現有的應用程序或數據系統。Connect實際上做了兩件事:用Source Connector從數據源(如DB)讀取數據並寫入Topic，再通過Sink Connector從Topic讀取數據並輸出到另壹端(如DB)，從而實現外部存儲與Kafka集群之間的消息數據傳輸。
接下來，我們將從Kafka的架構出發，重點介紹Kafka的主要組成部分和實現原理。Kafka支持消息持久性。消費者通過主動拉取消息來消費消息，客戶端負責維護訂閱狀態和訂閱關系。消息消費後不會立即刪除，但歷史消息會默認保留7天。因此，當支持多個訂閱者時，不需要復制消息，而只能存儲壹個副本。下面將詳細介紹各個組件的實現原理。
1.生產者
Producer是卡夫卡中的消息生產者，主要用於產生具有特定主題的消息。生產者產生的消息按主題分類，存儲在Kafka集群的代理中，具體是存儲在指定分區的目錄中，以段的形式存儲(。日誌文件和。索引文件)。
2.消費者
消費者是卡夫卡中的消費者，主要用於消費指定主題的消息。消費者通過主動拉取消費來自卡夫卡集群的消息，消費者必須屬於特定的消費群體。
3.主題
Kafka中的消息是按照主題分類的，主題支持多訂閱，壹個主題可以有多個訂閱消息的消費者。Kafka cluster的話題數量沒有限制。同壹題目的數據會被分到同壹個目錄下。壹個主題可以包含1到多個分區，所有分區的消息加起來就是壹個主題的所有消息。
4.劃分
在卡夫卡中，為了提高消息的消費速度，可以給每個話題分配多個分區，這就是我們之前說的。Kafka支持多個分區。默認情況下，主題消息只存儲在壹個分區中。主題所有分區的消息合並在壹起，就是壹個主題下的所有消息。每個分區都有壹個從0開始的編號，每個分區的數據都是有序的，但是不同分區的直接數據不能保證有序，因為不同分區需要不同的消費者消費，每個分區只能分配壹個消費者，但是壹個消費者可以同時擁有壹個話題的多個分區。
5.消費者群體
卡夫卡的每個消費者都屬於壹個特定的消費群體。如果未指定，則所有使用者都屬於同壹個默認使用者組。壹個消費者組由壹個或多個消費者組成，同壹消費者組中的消費者只消費同壹條消息壹次。每個消費群都有壹個唯壹的ID，即群ID，也稱為群名。消費群中的所有消費者協調訂閱壹個話題的所有分區，每個分區只能被壹個消費群中的壹個消費者消費，但可以被不同消費群中的壹個消費者消費。如下圖所示:
在層級關系上，消費者群體似乎對應著話題，消費者對應著話題下的分區。消費者組中的消費者數量和Topic * * *下的分區數量都決定了消息消費的並發性，分區數量決定了最終的並發性，因為壹個分區只能被壹個消費者消費。當壹個消費群中的消費者數量超過訂閱主題下的分區數量時，Kafka會給每個分區分配壹個消費者，多余的消費者會被閑置。當消費者組中的消費者數量小於當前調度的主題中的分區數量時，單個消費者將承擔多個分區的消費工作。如上圖所示，消費者組B中的每個消費者需要消費兩個分區中的數據，消費者組C中將有壹個額外的免費消費者4..綜上所述，同壹話題下的分區越多，消費者可以同時消費的就越多，消費的速度就越快，吞吐量就越高。同時，消費群體中的消費者數量需要控制在小於等於分區數量，最好是整數倍，比如1，2，4等。
6.段
考慮到消息消耗的性能，Kafka中的消息在每個分區中都是分段存儲的，即每1G消息創建壹個新的段，每個段包含兩個文件:。日誌文件和。索引文件。正如我們以前說過的。日誌文件是Kafka對Producer生成的消息的實際存儲，而。索引文件將相應消息的邏輯編號和物理偏移地址存儲在。日誌文件采用稀疏索引，從而加快數據查詢。的。日誌文件和。索引文件是壹壹對應，成對出現。下圖顯示了如何操作。日誌文件和。索引文件存在於分區中。
Kafka中的每條消息都有自己的邏輯偏移量(相對偏移量)和物理磁盤上的實際物理地址廉價位置，也就是說壹條消息在Kafka中有兩個位置:offset(相對偏移量)和Position(磁盤的物理偏移量地址)。在kafka的設計中，消息偏移量被作為段文件名的壹部分。段文件的命名規則是:全局分區的第壹個段從0開始，後續每個段文件名都是前壹個分區的最大偏移量(offset(Message，不是物理偏移量，實際物理地址需要映射到。日誌，以及在。日誌文件將在後面詳細介紹)。最大值為64位長，用20位數表示，前綴為0。
上圖顯示了。索引文件和。日誌文件。通過上圖，我們可以簡單介紹壹下卡夫卡分段尋找信息的過程:
1.根據要使用的下壹條消息的偏移量，假設這裏是7，使用二分搜索法來查找。索引文件名小於(必須小於，因為文件名編號等於當前偏移量的都是大於當前偏移量的消息)的當前偏移量編號最大的文件，自然在這裏找到000000000000000000.index。
2.在。索引文件，用二分搜索法找到偏移量小於等於指定偏移量的最大偏移量(這裏假設為7)，這裏找到的是6，然後索引文件中偏移量6指向的位置(物理偏移量地址)是258。
3.在。日誌文件，從磁盤位置258開始順序掃描，直到找到偏移量為7的消息。
至此，我們已經簡要介紹了Segment的基本組件的存儲和查詢原理。索引文件和。日誌文件。但是，我們會發現壹個問題:在。索引文件不是按順序連續存儲的。卡夫卡為什麽把索引文件設計得這麽不連續？這種不連續的索引設計方法稱為稀疏索引。在kafka中，使用稀疏索引來讀取索引。每當寫入4k數據時。日誌中，Kafka在。索引。使用稀疏索引的原因如下:
(1)索引稀疏存儲可以大大減少所占用的存儲空間。索引文件。
(2)稀疏索引文件較小，全部可以讀入內存，可以避免讀取索引時頻繁的IO磁盤操作，從而快速定位消息在。日誌文件。
7.消息
消息是實際發送和訂閱的信息，是實際的載體。生產者發給Kafka集群的每壹條消息都被Kafka打包成壹個消息對象，然後存儲在磁盤中，而不是直接存儲。磁盤上消息的物理結構如下。
其中key和值存儲的是實際的消息內容，長度不固定，其他的是消息內容的統計和描述，長度固定。因此，在尋找實際消息的過程中，磁盤指針會根據消息的偏移量和消息長度計算移動位數，以加快消息的搜索過程。這種加速的原因是卡夫卡的。日誌文件是按順序寫入的。向磁盤寫入數據時，意味著追加數據，不存在隨機寫入操作。
8.分區副本
最後，我們簡單說壹下卡夫卡中的分區副本機制。在0.8版本之前，卡夫卡沒有復制機制。創建主題時，可以指定主題的分區或副本數量。卡夫卡中的分區副本如下圖所示:
Kafka通過replication-factor控制消息副本存儲在幾個代理(服務器)中。壹般副本數等於代理數，同壹復制因子不能放在同壹個代理中。復制因子基於分區並區分角色；主副本稱為領導者(任何時候都只有壹個)，從副本稱為跟隨者(可以有多個)，處於同步狀態的副本稱為in-sync-replicas(ISR)。領導者負責讀寫數據，跟隨者不負責提供外部數據讀寫，只同步來自領導者的數據。消費者和生產者從領導者那裏讀寫數據，不與追隨者互動，所以卡夫卡沒有脫離讀寫。使用Leader同時讀寫的好處是減少了數據同步帶來的數據讀取延遲，因為Follower只有在數據從Leader同步後才能提供讀取服務。
如果壹個分區有三個副本因子，即使其中壹個死亡，也只會從剩下的兩個中選出壹個主因子，如下圖所示。但是另壹個副本不會在其他代理中啟動(因為如果在另壹個代理中啟動，必然有數據的復制和傳輸，會占用網絡IO很長時間。卡夫卡是壹個高通量的消息系統，這種情況是不允許發生的)。如果指定分區的所有副本都被掛起，如果使用者向指定分區發送數據，寫入將會不成功。消費者發送到指定分區的消息會先寫到Leader分區，然後需要寫到ISR列表中的其他分區副本，消息寫完後才能提交到offset。
至此，卡夫卡的結構和基本原理幾乎簡單介紹完畢。為了實現高吞吐量和容錯，Kafka還引入了很多優秀的設計思想，比如零拷貝、高並發網絡設計、順序存儲等，後面會講到。