深刻了解Kafka【一】概述與基礎架構

---

一、概述

Kafka是一個分佈式的、基於發佈訂閱的消息系統，主要解決應用解耦、異步消息、流量削峯等問題。

二、發佈訂閱模型

消息生產者將消息發佈到Topic中，同時有多個消息消費者訂閱該消息，消費者消費數據以後，並不會清除消息。屬於一對多的模式，如圖：

三、系統架構

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

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

下面介紹一下各個角色：

3.一、Producer

消息生產者，將消息push到Kafka集羣中的Broker。

3.二、Consumer

消息消費者，從Kafka集羣中pull消息，消費消息。

3.三、Consumer Group

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

3.四、Broker

一臺Kafka服務器就是一個Broker,一個集羣由多個Broker組成，每一個Broker能夠容納多個Topic.

3.五、Topic

消息的類別或者主題，邏輯上能夠理解爲隊列。Producer只關注push消息到哪一個Topic,Consumer只關注訂閱了哪一個Topic。

3.六、Partition

負載均衡與擴展性考慮，一個Topic能夠分爲多個Partition,物理存儲在Kafka集羣中的多個Broker上。可靠性上考慮，每一個Partition都會有備份Replica。

3.七、Replica

Partition的副本，爲了保證集羣中的某個節點發生故障時，該節點上的Partition數據不會丟失，且Kafka仍能繼續工做，因此Kafka提供了副本機制，一個Topic的每一個Partition都有若干個副本，一個Leader和若干個Follower。

3.八、Leader

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

3.九、Follower

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

3.九、Controller

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

3.九、ZooKeeper

Kafka經過Zookeeper存儲集羣的meta等信息。

四、Topic和Partition

一個Topic能夠認爲是一類信息，邏輯上的隊列，每條消息都要指定Topic。爲了使得Kafka的吞吐量能夠線性提升，物理上將Topic分紅一個或多個Partition。每一個Partition在存儲層面時append log文件，消息push進來後，會被追加到log文件的尾部，每條消息在文件中的位置成爲offset(偏移量)，offset是一個long型數字，惟一的標識一條信息。由於每條消息都追加到Partition的尾部，因此屬於磁盤的順序寫，效率很高。如圖：

五、網絡模型

Kafka的網絡模型基於Reactor模型，即響應模型。Kafka網絡模型分爲兩部分：Kafka客戶端即Consumer和Producer都是單線程的Reactor模型，Kafka服務端是多線程的Reactor模型。

5.一、單線程Reactor

如圖：

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

5.二、多線程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模式