1、概述

Kafka是一個分散式的、基於釋出訂閱的訊息系統，主要解決應用解耦、非同步訊息、流量削峰等問題。

2、釋出訂閱模型

訊息生產者將訊息釋出到Topic中，同時有多個訊息消費者訂閱該訊息，消費者消費資料之後，並不會清除訊息。屬於一對多的模式，如圖：

3、系統架構

網上找了個不錯的架構圖：

上圖中標識了一個kafka體系架構包括若干Producer、Broker、Consumer和一個zookeeper叢集。 再貼兩張帶有Topic和Partition的架構圖：

下面介紹一下各個角色：

3.1、Producer

訊息生產者，將訊息push到Kafka叢集中的Broker。

3.2、Consumer

訊息消費者，從Kafka叢集中pull訊息，消費訊息。

3.3、Consumer Group

消費者組，由一到多個Consumer組成，每個Consumer都屬於一個Consumer Group。消費者組在邏輯上是一個訂閱者。 消費者組內每個消費者負責消費不同分割槽的資料，一個分割槽只能由一個組內消費者消費；消費者組之間互不影響。 即每條訊息只能被Consumer Group中的一個Consumer消費；但是可以被多個Consumer Group組消費。這樣就實現了單播和多播。

3.4、Broker

一臺Kafka伺服器就是一個Broker,一個叢集由多個Broker組成，每個Broker可以容納多個Topic.

3.5、Topic

訊息的類別或者主題，邏輯上可以理解為佇列。Producer只關注push訊息到哪個Topic,Consumer只關注訂閱了哪個Topic。

3.6、Partition

負載均衡與擴充套件性考慮，一個Topic可以分為多個Partition,物理儲存在Kafka叢集中的多個Broker上。可靠性上考慮，每個Partition都會有備份Replica。

3.7、Replica

Partition的副本，為了保證叢集中的某個節點發生故障時，該節點上的Partition資料不會丟失，且Kafka仍能繼續工作，所以Kafka提供了副本機制，一個Topic的每個Partition都有若干個副本，一個Leader和若干個Follower。

3.8、Leader

Replica的主角色，Producer與Consumer只跟Leader互動。

3.9、Follower

Replica的從角色，實時從Leader中同步資料，保持和Leader資料的同步。Leader發生故障時，某個Follower會變成新的Leader。

3.9、Controller

Kafka叢集中的其中一臺伺服器，用來進行Leader election以及各種Failover（故障轉移）。

3.9、ZooKeeper

Kafka通過Zookeeper儲存叢集的meta等資訊。

4、Topic和Partition

一個Topic可以認為是一類資訊，邏輯上的佇列，每條訊息都要指定Topic。為了使得Kafka的吞吐量可以線性提高，物理上將Topic分成一個或多個Partition。每個Partition在儲存層面時append log檔案，訊息push進來後，會被追加到log檔案的尾部，每條訊息在檔案中的位置成為offset(偏移量)，offset是一個long型數字，唯一的標識一條資訊。因為每條訊息都追加到Partition的尾部，所以屬於磁碟的順序寫，效率很高。如圖：

5、網路模型

Kafka的網路模型基於Reactor模型，即響應模型。Kafka網路模型分為兩部分：Kafka客戶端即Consumer和Producer都是單執行緒的Reactor模型，Kafka服務端是多執行緒的Reactor模型。

5.1、單執行緒Reactor

如圖：

Reactor執行緒負責多路分離套接字，Accept新連線，並分派請求到Handler處理器。

5.2、多執行緒Reactor

以下來自；訊息中介軟體—簡談Kafka中的NIO網路通訊模型 如圖：

• Acceptor：1個接收執行緒，負責監聽新的連線請求，同時註冊OP_ACCEPT 事件，將新的連線按照"round robin"方式交給對應的 Processor 執行緒處理；
• Processor：N個處理器執行緒，其中每個 Processor 都有自己的 selector，它會向 Acceptor 分配的 SocketChannel 註冊相應的 OP_READ 事件，N 的大小由“num.networker.threads”決定；
• KafkaRequestHandler：M個請求處理執行緒，包含線上程池—KafkaRequestHandlerPool內部，從RequestChannel的全域性請求佇列—requestQueue中獲取請求資料並交給KafkaApis處理，M的大小由“num.io.threads”決定；
• RequestChannel：其為Kafka服務端的請求通道，該資料結構中包含了一個全域性的請求佇列 requestQueue和多個與Processor處理器相對應的響應佇列responseQueue，提供給Processor與請求處理執行緒KafkaRequestHandler和KafkaApis交換資料的地方。
• NetworkClient：其底層是對 Java NIO 進行相應的封裝，位於Kafka的網路介面層。Kafka訊息生產者物件—KafkaProducer的send方法主要呼叫NetworkClient完成訊息傳送；
• SocketServer：其是一個NIO的服務，它同時啟動一個Acceptor接收執行緒和多個Processor處理器執行緒。提供了一種典型的Reactor多執行緒模式，將接收客戶端請求和處理請求相分離；
• KafkaServer：代表了一個Kafka Broker的例項；其startup方法為例項啟動的入口；
• KafkaApis：Kafka的業務邏輯處理Api，負責處理不同型別的請求；比如“傳送訊息”、“獲取訊息偏移量—offset”和“處理心跳請求”等；

參考

深入淺出理解基於 Kafka 和 ZooKeeper 的分散式訊息佇列 kafka架構原理 阿里大牛實戰歸納——Kafka架構原理 Kafka架構圖 Kafka 設計解析（一）：Kafka 背景及架構介紹 訊息中介軟體—簡談Kafka中的NIO網路通訊模型 Reactor模式