基礎(chǔ)

簡介

特點：

• 高吞吐、低延遲：kafka每秒可以處理幾十萬條消息，延遲最低只有幾毫秒，每個Topic可以分多個Partition，Consumer Group對Partition進行Consumer操作
• 可擴展性：Kafka集群支持熱擴展
• 持久性、可靠性：消息被持久化到本地磁盤，并且支持數(shù)據(jù)備份防止數(shù)據(jù)丟失
• 容錯性：允許集群中節(jié)點失敗（若副本數(shù)量為n，則允許n-1個節(jié)點失敗）
• 高并發(fā)：支持數(shù)千個客戶端同時讀寫

應(yīng)用場景

包括：

• 日志收集：一個公司可以用Kafka可以收集各種服務(wù)的log，通過kafka以統(tǒng)一接口服務(wù)的方式開放給各種Consumer，如Hadoop、HBase等
• 消息系統(tǒng)：解耦和生產(chǎn)者和消費者、緩存消息等
• 用戶活動跟蹤：記錄web或app用戶的各種活動，如瀏覽網(wǎng)頁、搜索等，這些活動信息被各個服務(wù)器發(fā)布到Kafka的Topic中，然后訂閱者通過訂閱這些Topic來做實時的監(jiān)控分析，或存儲到Hadoop、數(shù)據(jù)倉庫中做離線分析和挖掘
• 運營指標(biāo)：記錄運營監(jiān)控數(shù)據(jù)。包括收集各種分布式應(yīng)用的數(shù)據(jù)，生產(chǎn)各種操作的集中反饋，比如報警和報告
• 流式處理：如Spark Streaming和Flink

概念

ISR：In-Sync Replicas，副本同步隊列
OSR：Out-of-Sync Replicas，非副本同步隊列
AR：Assigned Replicas所有副本

ISR是由Leader維護，Follower從Leader同步數(shù)據(jù)有一些延遲，超過配置的閾值會把Follower剔除出ISR，存入OSR列表，新加入的Follower也會先存放在OSR中。AR=ISR+OSR。

Offset：偏移量
LEO：Log End Offset，當(dāng)前日志文件中下一條，每個副本最大的Offset
HW：High Watermark，高水位，通常被用在流式處理領(lǐng)域，以表征元素或事件在基于時間層面上的進度。是ISR隊列中最小的LEO。消費者最多只能消費到HW所在的位置上一條信息。

LSO：Last Stable Offset，對未完成的事務(wù)而言，LSO的值等于事務(wù)中第一條消息的位置(First Unstable Offset)，對已完成的事務(wù)而言，它的值同HW相同
LW：Low Watermark，低水位，代表AR集合中最小的LSO值。

負載均衡

Kafka的負載均衡就是每個Broker都有均等的機會為Kafka的客戶端（生產(chǎn)者與消費者）提供服務(wù)，可以將負載分散到集群中的所有機器上。通過智能化的分區(qū)領(lǐng)導(dǎo)者選舉來實現(xiàn)負載均衡，可在集群的所有機器上均勻分散各個Partition的Leader，從而整體上實現(xiàn)負載均衡。

故障處理與轉(zhuǎn)移

故障分Follower故障和Leader故障：

• Follower故障

Follower發(fā)生故障后會被臨時踢出ISR，待該Follower恢復(fù)后，Follower會讀取本地磁盤記錄的上次的HW，并將log文件高于HW的部分截取掉，從HW開始與Leader進行同步。等該Follower的LEO大于等于該Partition的HW，即Follower追上Leader后，可重新加入ISR。

• Leader故障

Leader發(fā)生故障后，會從ISR中選出一個新的Leader，為保證多個副本之間的數(shù)據(jù)一致性，其余的Follower會先將各自的log文件高于HW的部分截掉，然后從新的Leader同步數(shù)據(jù)。

注意：這只能保證副本之間的數(shù)據(jù)一致性，并不能保證數(shù)據(jù)不丟失或者不重復(fù)

Kafka的故障轉(zhuǎn)移是通過使用會話機制實現(xiàn)的，每臺Kafka服務(wù)器啟動后會以會話的形式把自己注冊到ZK服務(wù)器上。一旦服務(wù)器運轉(zhuǎn)出現(xiàn)問題，就會導(dǎo)致與ZK的會話不能維持從而超時斷連，此時Kafka集群會選舉出另一臺服務(wù)器來完全替代這臺服務(wù)器繼續(xù)提供服務(wù)。

分區(qū)

Q：分區(qū)的作用？
A：實現(xiàn)Broker負載均衡。對于消費者來說，提高并發(fā)度。

Q：一個Topic對應(yīng)幾個Partition？

Q：分區(qū)取值原則？
A：按照如下順序判斷：

• 指明Partition的情況下，直接將指明的值作為Partition值
• 沒有指明Partition值但有Key的情況下，將Key的Hash值與Topic的Partition值進行取余得到Partition值
• 既沒有Partition值又沒有Key值的情況下，第一次調(diào)用時隨機生成一個整數(shù)（后面每次調(diào)用在這個整數(shù)上自增），將這個值與Topic可用的Partition總數(shù)取余得到Partition值，即round-robin算法

Q：Kafka分區(qū)數(shù)可以增加或減少嗎？
A：可使用bin/kafka-topics.sh命令增加Kafka的分區(qū)數(shù)，但不支持減少分區(qū)數(shù)。

Kafka分區(qū)數(shù)據(jù)不支持減少是由很多原因的，比如減少的分區(qū)內(nèi)數(shù)據(jù)放到哪里去？是刪除，還是保留？刪除的話，這些沒消費的消息不就丟了。如果保留這些消息如何放到其他分區(qū)里面？追加到其他分區(qū)后面的話那么就破壞Kafka單個分區(qū)的有序性。如果要保證刪除分區(qū)數(shù)據(jù)插入到其他分區(qū)保證有序性，實現(xiàn)起來邏輯就會非常復(fù)雜。

Q：Kafka新建的分區(qū)會在哪個目錄下創(chuàng)建？
A：在啟動Kafka集群之前，需提前配置好log.dirs或log.dir參數(shù)，其值是Kafka數(shù)據(jù)的存放目錄，可配置多個目錄，使用逗號分隔，通常這些目錄是分布在不同的磁盤上用于提高讀寫性能。

如果log.dirs參數(shù)只配置一個目錄，那么分配到各個Broker上的分區(qū)肯定只能在這個目錄下創(chuàng)建文件夾用于存放數(shù)據(jù)。

如果log.dirs參數(shù)配置多個目錄，Kafka會在哪個文件夾中創(chuàng)建分區(qū)目錄呢？Kafka會在含有分區(qū)目錄最少的文件夾中創(chuàng)建新的分區(qū)目錄，分區(qū)目錄名為Topic名+分區(qū)ID。分區(qū)文件夾總數(shù)最少的目錄，而不是磁盤使用量最少的目錄！即，如果你給log.dirs參數(shù)新增一個新的磁盤，新的分區(qū)目錄肯定是先在這個新的磁盤上創(chuàng)建直到這個新的磁盤目錄擁有的分區(qū)目錄不是最少為止。

ACK

Producer有三種ACK機制

• 0：相當(dāng)于異步操作，Producer不需要Leader給予回復(fù)，發(fā)送完就認為成功，繼續(xù)發(fā)送下一批消息。此機制具有最低延遲，但是持久性可靠性也最差，當(dāng)服務(wù)器發(fā)生故障時，很可能發(fā)生數(shù)據(jù)丟失
• 1：默認設(shè)置。表示Producer要Leader確認已成功接收數(shù)據(jù)才發(fā)送下一批消息。不等待Follower副本的確認。如果Leader宕機，Follower尚未復(fù)制時，數(shù)據(jù)就會丟失。此機制提供較好的持久性和較低的延遲性。
• -1：Leader接收到消息之后，還必須要求ISR列表里跟Leader保持同步的那些Follower都確認消息已同步，Producer才發(fā)送下一批消息。此機制持久性可靠性最好，但延時性最差。

副本同步策略

有兩種：

方案	優(yōu)點	缺點
半數(shù)以上完成同步，就發(fā)送ACK	延遲低	選舉新Leader，容忍n臺節(jié)點的故障，需2n+1個副本
全部完成同步，才發(fā)送ACK	選舉新Leader，容忍n臺節(jié)點的故障，需n+1個副本	延遲高

選方案二原因：

1. 方案二只需n+1個副本，因Kafka每個分區(qū)都有大量的數(shù)據(jù)，第一種方案會造成大量數(shù)據(jù)的冗余
2. 雖然方案二的網(wǎng)絡(luò)延遲會比較高，但網(wǎng)絡(luò)延遲對Kafka的影響較小

不丟失

不能保證消息不丟失，只能盡力。措施如下：

• 持久性：Kafka使用磁盤存儲消息，這樣即使在斷電等異常情況下，消息也不會丟失。Kafka使用日志文件（Log）來存儲消息，每個分區(qū)都有一個或多個日志段（Log Segment）來持久化消息
• 復(fù)制機制：Kafka使用副本機制來保證消息的可靠性。每個分區(qū)都可以配置多個副本（Replica），一個Leader副本和若干個Follower副本。生產(chǎn)者發(fā)送的消息首先寫入領(lǐng)導(dǎo)者副本，然后通過副本同步機制復(fù)制到追隨者副本，只有在所有副本都成功寫入后才認為消息提交成功
• 消息確認機制：即上文的ACK機制

去重

Kafka不能完全保證消息的重復(fù)發(fā)送和投遞，需要借助于業(yè)務(wù)系統(tǒng)?？蓮娜齻€端來保證消息的唯一性：

• Producer：通過在消息的鍵Key中包含某種唯一標(biāo)識字段來實現(xiàn)。當(dāng)相同鍵的消息發(fā)送到Kafka時，Kafka會根據(jù)鍵值對消息進行分區(qū)，因此相同鍵的消息會被發(fā)送到同一個分區(qū)中，從而保證相同鍵的消息在同一分區(qū)中的順序和唯一性
• Kafka：可通過使用帶有去重插件或Kafka Streams等工具來實現(xiàn)消息去重功能
• Consumer：引入緩存或數(shù)據(jù)庫組件，判斷是否已經(jīng)消費過此條消息，判斷依據(jù)需要依賴于Producer定義的唯一字段

冪等性

和上面的去重，很多場景下是一回事。

有序性

Kafka中的每個Partition中的消息在寫入時都是有序的，一個Partition只能由一個消費者去消費，可以在里面保證消息的順序性。但是分區(qū)之間的消息是不保證有序的。

消費者

在創(chuàng)建一個消費者程序時，如果沒有指定消費者組ID，則該消費者程序會被分配到一個默認的消費者組。

對應(yīng)源碼org.apache.kafka.clients.consumer.KafkaConsumer，實現(xiàn)Consumer<K, V>接口。

在Kafka 0.10.0.x版本以前，消費狀態(tài)信息維護在ZK集群里，以后的版本，維護在兩個地方：

• 內(nèi)部主題__consumer_offsets
• 內(nèi)存數(shù)據(jù)：解決讀取內(nèi)部Topic速度慢問題，構(gòu)建三元組來維護最新的偏移量信息。支持外部存儲化

__consumer_offsets
以消費者組（Group）、主題（Topic）和分區(qū)（Partition）作為組合主鍵，所有消費者程序產(chǎn)生的偏移量都會提交到該內(nèi)部主題中進行存儲。極端重要數(shù)據(jù)，故而設(shè)置其應(yīng)答Ack級別設(shè)置為?1。

再均衡

即Rebalance，重新均衡消費者消費，在同一個消費者組當(dāng)中，分區(qū)的所有權(quán)從一個消費者轉(zhuǎn)移到另外一個消費者。會觸發(fā)Rebalance機制的場景：

• 消費者增加、減少（退出、下線、宕機）
• Partition增加
• Coordinator宕機
• 訂閱的Topic數(shù)發(fā)生變化時

Rebalance的過程如下：

• 所有成員都向Coordinator發(fā)送JoinGroupRequest請求入組。一旦所有成員都發(fā)送請求，Coordinator會從中選擇一個Consumer擔(dān)任Leader角色，并把組成員信息以及訂閱信息，即JoinGroupRespone發(fā)給Leader
• Leader開始分配消費方案，指明具體哪個Consumer負責(zé)消費哪些Topic的哪些Partition。
• 一旦完成分配，Leader會將這個方案，即SyncGroupRequest發(fā)給Coordinator。Coordinator接收到分配方案之后會把方案發(fā)給各個Consumer，這樣組內(nèi)的所有成員就都知道自己應(yīng)該消費哪些分區(qū)

消費者組協(xié)調(diào)器

GroupCoordinator，負責(zé)協(xié)調(diào)多個消費者之間的行為，以確保他們能夠正確地從Kafka主題中消費數(shù)據(jù)。由Kafka集群中的一個或多個服務(wù)器組成，主要作用包括：

• 分區(qū)分配策略：消費者協(xié)調(diào)器負責(zé)決定哪個消費者負責(zé)消費主題中的哪個分區(qū)。在消費者組內(nèi)，每個分區(qū)只能被一個消費者消費，而消費者協(xié)調(diào)器會根據(jù)一定的算法（如輪詢、粘性分區(qū)等）來分配分區(qū)給各個消費者。
• 消費者的加入和離開：當(dāng)有新消費者加入或離開消費者組時，消費者協(xié)調(diào)器會負責(zé)處理相關(guān)的邏輯。新加入的消費者需要被分配新的分區(qū)，而離開的消費者需要將其負責(zé)的分區(qū)重新分配給其他消費者。
• 負載均衡：消費者協(xié)調(diào)器還會負責(zé)實現(xiàn)消費者的負載均衡。在有多個消費者的場景下，如果一個消費者的消費速度過快，而其他消費者消費速度較慢，可能會導(dǎo)致某些分區(qū)的數(shù)據(jù)被快速消費完，而其他分區(qū)的數(shù)據(jù)仍然保留在Kafka中。消費者協(xié)調(diào)器會根據(jù)消費者的消費情況，動態(tài)地調(diào)整分區(qū)的分配，以確保整個消費組的負載均衡。
• 故障轉(zhuǎn)移：當(dāng)某個消費者出現(xiàn)故障時，消費者協(xié)調(diào)器會將其負責(zé)的分區(qū)轉(zhuǎn)移到其他健康的消費者上，以保證整個消費組的高可用性。

對應(yīng)源碼org.apache.kafka.clients.consumer.internals.ConsumerCoordinator：

實現(xiàn)原理：

消費者和消費者組的關(guān)系

每個消費者從屬于消費組。具體關(guān)系如下：

消費者組特性：

• 一個消費者組，可以有一個或多個消費者程序；
• 消費者組名（GroupId）通常由一個字符串表示，具有唯一性；
• 如果一個消費者組訂閱主題，則該主題中的每個分區(qū)只能分配給某一個消費者組中的某一個消費者程序。

消費者程序的數(shù)量盡量不要超過主題的最大分區(qū)數(shù)，多出來的消費者程序是空閑的，會浪費系統(tǒng)資源。

與其他MQ中間件的比較

比如RabbitMQ，ActiveMQ，RocketMQ，Apache Pulsar。

Kafka對比Pulsar

Apache Kafka和Apache Pulsar都是流處理平臺，用于處理和傳輸大規(guī)模的實時數(shù)據(jù)流。盡管它們在目標(biāo)上有很多相似之處，但在架構(gòu)、特性、性能等方面存在顯著差異。以下是兩者的詳細對比：

架構(gòu)

• Kafka
  單層架構(gòu)：Kafka使用單層架構(gòu)，所有消息存儲和傳輸功能都由Kafka Broker負責(zé)。
  存儲：Kafka使用分區(qū)日志存儲消息，每個分區(qū)在一個或多個Broker上持久化。
  協(xié)調(diào)和管理：Kafka依賴Apache ZooKeeper進行集群元數(shù)據(jù)的管理、分區(qū)Leader選舉等協(xié)調(diào)工作。
• Pulsar
  多層架構(gòu)：Pulsar采用多層架構(gòu)，包括Pulsar Brokers、BookKeeper和ZooKeeper。
  Pulsar Brokers：處理生產(chǎn)者和消費者的請求，執(zhí)行負載均衡和元數(shù)據(jù)管理。
  Apache BookKeeper：用于消息持久化，提供高效的分布式日志存儲。
  Apache ZooKeeper：用于協(xié)調(diào)和管理集群元數(shù)據(jù)。
  存儲：Pulsar使用BookKeeper進行存儲，支持水平擴展和高性能的日志存儲。

消息模型

• Kafka
  主題和分區(qū)：Kafka的主題被分為多個分區(qū)，消息按順序?qū)懭敕謪^(qū)。
  消息保留：消息保留策略可以基于時間或日志大小，保留期內(nèi)的消息可以被多次消費。
• Pulsar
  主題類型：Pulsar支持多種主題類型（獨占、共享、失敗轉(zhuǎn)移和關(guān)鍵共享），靈活應(yīng)對不同的消費模式。
  分區(qū)主題：類似于Kafka，Pulsar也支持分區(qū)主題，但可以動態(tài)增加分區(qū)數(shù)量。
  消息保留：Pulsar支持消息保留策略，可以按時間或大小配置，同時支持基于事件時間的TTL（Time-to-Live）。

性能和可擴展性

• Kafka
  吞吐量：Kafka的高吞吐量得益于其高效的順序?qū)懭牒头謪^(qū)日志存儲機制。
  擴展性：Kafka可以水平擴展，通過增加Broker實例來提高集群容量，但增加分區(qū)數(shù)后無法減少。
• Pulsar
  吞吐量：Pulsar通過分層架構(gòu)和BookKeeper提供高吞吐量，適合低延遲寫入和讀取。
  擴展性：Pulsar可以動態(tài)擴展，通過增加Brokers和Bookies實現(xiàn)無縫擴展，分區(qū)數(shù)可以動態(tài)調(diào)整。

消費者模型

• Kafka
  消費模式：Kafka提供消費者組，通過分配分區(qū)給消費者實現(xiàn)負載均衡。一個分區(qū)只能由一個消費者組內(nèi)的一個消費者消費。
  消費位置管理：消費者偏移量存儲在Kafka主題內(nèi)或ZooKeeper中。
• Pulsar
  消費模式：Pulsar支持多種消費模式，包括獨占、共享、失敗轉(zhuǎn)移和關(guān)鍵共享，提供更靈活的消費方式。
  消費位置管理：Pulsar的偏移量（游標(biāo)）管理由Broker處理，并持久化在BookKeeper中。

功能特性

• Kafka
  事務(wù)支持：Kafka支持事務(wù)消息，確保消息的原子寫入和消費。
  流處理：Kafka Streams和ksqlDB提供了強大的流處理功能，支持復(fù)雜的數(shù)據(jù)流處理任務(wù)。
• Pulsar
  多租戶支持：Pulsar原生支持多租戶，通過命名空間實現(xiàn)隔離和資源限制。
  延時消息：Pulsar支持消息定時發(fā)布，允許生產(chǎn)者設(shè)置消息的延遲時間。
  函數(shù)（Functions）：Pulsar Functions提供輕量級的流處理功能，可以在Broker內(nèi)部運行用戶定義的函數(shù)，處理流數(shù)據(jù)。

社區(qū)和生態(tài)系統(tǒng)

• Kafka
  社區(qū)支持：Kafka擁有龐大且活躍的社區(qū)，豐富的文檔和教程資源。
  生態(tài)系統(tǒng)：Kafka擁有豐富的生態(tài)系統(tǒng)，如Confluent提供的商業(yè)支持和工具，Kafka Streams、ksqlDB等。
• Pulsar
  社區(qū)支持：Pulsar的社區(qū)正在快速增長，提供官方文檔、教程和示例代碼。
  生態(tài)系統(tǒng)：Pulsar生態(tài)系統(tǒng)也在擴展中，包括Pulsar Functions、Pulsar IO連接器等。

Kafka適合需要高吞吐量、簡單架構(gòu)以及現(xiàn)有生態(tài)系統(tǒng)支持的場景，尤其是在需要復(fù)雜流處理的情況下。
Pulsar則在多租戶支持、動態(tài)擴展、延遲消息處理等方面表現(xiàn)出色，適合需要靈活消費模式和復(fù)雜存儲管理的場景。

Topic

刪除Topic流程

Kafka控制器在啟動時會創(chuàng)建一個獨立的刪除線程，用來執(zhí)行主題刪除操作。刪除線程會檢測刪除的主題集合是否為空：

• 如果刪除主題的集合為空，則刪除線程就會被掛起；
• 如果刪除主題的集合不為空，則立即觸發(fā)刪除邏輯。刪除線程會通知Kafka的所有代理節(jié)點，刪除這個主題的所有分區(qū)。接著，Kafka控制器會更新ZK系統(tǒng)信息，清除各種緩存，將標(biāo)記刪除的主題信息移除。
  

ZooKeeper

Kafka各Broker在啟動時都要在ZK上注冊，由ZK統(tǒng)一協(xié)調(diào)管理。如果任何節(jié)點失敗，可通過ZK從先前提交的偏移量中恢復(fù)，因為它會做周期性提交偏移量工作。同一個Topic的消息會被分成多個分區(qū)并將其分布在多個Broker上，這些分區(qū)信息及與Broker的對應(yīng)關(guān)系也是ZK在維護。

Kafka 2.8.0版本引入Kafka原生集群管理新特性，官方說法是Kafka Raft Metadata Mode。Kafka可以獨立運行，不再強制依賴于ZK來提供集群管理和元數(shù)據(jù)存儲功能。

基于Raft一致性協(xié)議實現(xiàn)，使得Kafka Broker可以直接通過Raft協(xié)議來選舉領(lǐng)導(dǎo)者和維護元數(shù)據(jù)的一致性，減少外部依賴，使Kafka集群的部署和維護更簡單。

Pull還是Push

Producer將消息Push到Broker集群，Consumer從Broker集群Pull消息。

縱觀各大消息中間件，Producer將消息Push到Broker集群。Apache Pulsar可能是唯一的例外，Broker可以主動從Producer拉取消息，而不是等待Consumer。在某些特定場景下可能會有用，如需要Broker對消息進行一些處理或者過濾，然后再轉(zhuǎn)發(fā)給Consumer。

消息如何從Broker觸達到Consumer，各大中間件的實現(xiàn)有Push和Pull模式的不同。如Scribe和Flume采用push模式，即Broker將消息推送到下游的Consumer。

Push模式的缺點：由Broker決定消息推送的速率，對于不同消費速率的Consumer就不太好處理。消息系統(tǒng)都致力于讓Consumer以最大的速率快速消費消息，當(dāng)Broker推送速率遠大于Consumer消費速率時，Consumer可能會崩潰。

Pull模式的好處：Consumer可以自主決定是否批量的從broker拉取數(shù)據(jù)。Push模式必須在不知道下游Consumer消費能力和消費策略的情況下決定是立即推送每條消息還是緩存之后批量推送。如果為了避免Consumer崩潰而采用較低的推送速率，將可能導(dǎo)致一次只推送較少的消息而造成浪費。Pull模式下，Consumer就可以根據(jù)自己的消費能力去決定這些策略。

Pull的缺點：如果Broker沒有可供消費的消息，將導(dǎo)致Consumer不斷在循環(huán)中輪詢，直到新消息到達。為了避免這點，Kafka有個參數(shù)可以讓Consumer阻塞知道新消息到達（當(dāng)然也可以阻塞直到消息的數(shù)量達到某個特定的量），這樣就可以批量發(fā)。

消息事務(wù)

消息傳輸?shù)氖聞?wù)（又叫消息投遞語義）定義通常有以下三種級別：

• 最多一次：消息不會被重復(fù)發(fā)送，最多被傳輸一次，但也有可能一次不傳輸
• 最少一次：消息不會被漏發(fā)送，最少被傳輸一次，但也有可能被重復(fù)傳輸
• 精確一次：不會漏傳輸也不會重復(fù)傳輸，每個消息都傳輸一次

腳本

分為Linux和Windows版；隨著Kafka版本的迭代更新，腳本數(shù)量一直在新增。每個腳本的使用又有相應(yīng)的參數(shù)和用途，雖然不同腳本之間參數(shù)的命名和用途有跡可循，都有規(guī)律。

需要另起一篇。面試時提到2~3個即可。

工具

和上面的腳步有部分重復(fù)：

• Kafka遷移工具：它有助于將代理從一個版本遷移到另一個版本
• 消費者檢查：對于指定的主題集和消費者組，可顯示主題、分區(qū)、所有者

Broker

一臺Kafka服務(wù)器就是一個Broker，集群由多個Broker組成，一個Broker可以容納多個Topic。

如何判斷一個Broker是否還存活？

• Broker必須可以維護和ZK的連接，通過心跳機制檢查每個結(jié)點的連接。
• 如果Broker是個Follower，它必須能及時同步Leader的寫操作，延時不能太久。

配置

配置文件：

• server.properties：
• producer.properties：
• consumer.properties：
• zookeeper.properties：

優(yōu)化

缺點

包括：

• 批量發(fā)送，數(shù)據(jù)并非真正的實時；
• 不支持MQTT協(xié)議；
• 不支持物聯(lián)網(wǎng)傳感數(shù)據(jù)直接接入；
• 僅支持統(tǒng)一分區(qū)內(nèi)消息有序，無法實現(xiàn)全局消息有序；
• 監(jiān)控不完善，需要安裝插件；
• 低版本依賴ZK進行元數(shù)據(jù)管理；

進階

批處理

吞吐量

Kafka的設(shè)計是把所有的消息都寫入速度低容量大的硬盤，以此來換取更強的存儲能力，但實際上，使用硬盤并沒有帶來過多的性能損失。技術(shù)要點：

• 順序讀寫
• 文件分段
• 批量發(fā)送
• 數(shù)據(jù)壓縮

順序讀寫
操作系統(tǒng)每次從磁盤讀寫數(shù)據(jù)的時候，需要先尋址，也就是先要找到數(shù)據(jù)在磁盤上的物理位置，然后再進行數(shù)據(jù)讀寫，如果是機械硬盤，尋址就需要較長的時間。
Kafka的設(shè)計中，數(shù)據(jù)其實是存儲在磁盤上面，一般來說，會把數(shù)據(jù)存儲在內(nèi)存上面性能才會好。
但是Kafka用的是順序?qū)?#xff0c;追加數(shù)據(jù)是追加到末尾，磁盤順序?qū)懙男阅軜O高，在磁盤個數(shù)一定，轉(zhuǎn)數(shù)達到一定的情況下，基本和內(nèi)存速度一致。
隨機寫的話是在文件的某個位置修改數(shù)據(jù)，性能會較低。

零拷貝

消息格式

消息格式經(jīng)過四次大變化。

文件存儲

Kafka中消息是以Topic進行分類，生產(chǎn)者通過Topic向broker發(fā)送消息，消費者通過Topic讀取數(shù)據(jù)。物理層面，一個Topic可以分成若干個Partition，Partition還可以細分為segment：

• Kafka把Topic中一個parition大文件分成多個小文件段，通過多個小文件段，就容易定期清除或刪除已經(jīng)消費完文件，減少磁盤占用。
• 通過索引信息可以快速定位message和確定response的最大大小。
• 通過index元數(shù)據(jù)全部映射到memory，可以避免segment file的IO磁盤操作。
• 通過索引文件稀疏存儲，可以大幅降低index文件元數(shù)據(jù)占用空間大小

多租戶

多租戶技術(shù)，Multi-Tenancy Technology，是一種軟件架構(gòu)技術(shù)，實現(xiàn)如何在多用戶的環(huán)境下共用相同的系統(tǒng)或程序組件，并且仍可確保各用戶間數(shù)據(jù)的隔離性。

通過配置哪個主題可以生產(chǎn)或消費數(shù)據(jù)來啟用多租戶，也有對配額的操作支持。管理員可以對請求定義和強制配額，以控制客戶端使用的Broker資源。

監(jiān)控

Kafka集群的監(jiān)控是確保其性能和穩(wěn)定性的重要組成部分。有效的監(jiān)控可以幫助預(yù)防問題，快速定位和解決故障，保障系統(tǒng)的正常運行。

監(jiān)控的關(guān)鍵指標(biāo)如下：

• Broker指標(biāo)：

Broker的CPU、內(nèi)存和磁盤使用情況
網(wǎng)絡(luò)流量和I/O性能
活躍的Controller數(shù)量

• 主題和分區(qū)指標(biāo)：

每個主題和分區(qū)的消息吞吐量。
副本同步情況ISR
分區(qū)的日志大小和滯后情況

• 生產(chǎn)者指標(biāo)：

生產(chǎn)者的消息發(fā)送速率和失敗率
請求的延遲時間

• 消費者指標(biāo)：

消費者的消費速率和失敗率
消費者延遲（消費滯后）

• ZooKeeper指標(biāo)：

ZK節(jié)點的狀態(tài)和會話數(shù)
ZK的請求處理延遲

常用監(jiān)控方案：

• Kafka自帶工具：適用于簡單的監(jiān)控和管理任務(wù)，但功能較為基礎(chǔ)，缺乏可視化和綜合的監(jiān)控能力：
  • kafka-topics.sh：管理和查看主題信息
  • kafka-consumer-groups.sh：管理和查看消費者組信息
  • kafka-configs.sh：查看和修改配置
  • kafka-run-class.sh kafka.tools.GetOffsetShell：獲取主題的最新偏移量
• Kafka 自帶的 JMX（Java Management Extensions）：Kafka內(nèi)部通過JMX暴露許多關(guān)鍵的指標(biāo)，可用來監(jiān)控Kafka集群的運行狀態(tài)。使用JMX可以獲取關(guān)于Broker、生產(chǎn)者、消費者、主題和分區(qū)的詳細統(tǒng)計信息。
• 使用第三方監(jiān)控工具和框架：包括Prometheus、Grafana、ELK Stack等。
• 定制化監(jiān)控和告警：根據(jù)具體的業(yè)務(wù)需求，定制化監(jiān)控方案和告警策略，如自定義指標(biāo)收集、告警規(guī)則等。確保在關(guān)鍵指標(biāo)出現(xiàn)異常時，能夠及時收到告警并進行處理。

工具

• Kafka Manager：由Yahoo開發(fā)的Kafka監(jiān)控和管理工具。提供集群管理、主題創(chuàng)建和刪除、分區(qū)重分配、消費者監(jiān)控等功能。適合中小型Kafka集群的管理和監(jiān)控。
• Prometheus + Grafana：使用Prometheus JMX Exporter將Kafka的JMX指標(biāo)導(dǎo)出到Prometheus。Grafana可與Prometheus集成，創(chuàng)建實時監(jiān)控儀表盤。適合大規(guī)模Kafka集群的監(jiān)控和數(shù)據(jù)可視化。
• Confluent Control Center：Confluent提供的商業(yè)化Kafka監(jiān)控和管理工具。提供全面的Kafka集群監(jiān)控、流處理監(jiān)控、Schema Registry管理等功能。適合企業(yè)級Kafka部署，提供強大的監(jiān)控和管理功能。
• Burrow：LinkedIn開發(fā)的Kafka消費者延遲監(jiān)控工具。專注于監(jiān)控消費者延遲，幫助識別和解決消費者消費滯后的問題。適合需要精確監(jiān)控消費者延遲的場景。
• Elastic Stack(ELK)：使用Filebeat或Metricbeat收集Kafka日志和指標(biāo)存儲到ES中，使用Kibana創(chuàng)建可視化儀表盤，實時監(jiān)控Kafka集群狀態(tài)。適合需要對Kafka集群進行日志分析和指標(biāo)監(jiān)控的場景。

安全

在0.9版本之前，Kafka集群是沒有安全機制的。當(dāng)前Kafka系統(tǒng)支持多種認證機制：SSL、SASL/Kerberos、SASL/PLAIN、SASL/SCRAM。

認證范圍包括：

• 客戶端和Broker節(jié)點之間的連接認證
• Broker節(jié)點之間的連接認證
• Broker節(jié)點與ZK系統(tǒng)之間的連接認證

參考

• Kafka新建的分區(qū)會在哪個目錄下創(chuàng)建