本文目錄：

一、消息隊列 Apache Pulsar Pulsar 與 Kafka 對比二、Kafka基礎三、Kafka架構及組件四、Kafka集群操作五、Kafka的JavaAPI操作六、Kafka中的數據不丟失機制七、Kafka配置文件說明八、CAP理論九、Kafka中的CAP機制十、Kafka監控及運維十一、Kafka大廠面試題

Kafka 涉及的知識點如下圖所示，本文將逐一講解：

本文檔參考瞭關於 Kafka 的官網及其他眾多資料整理而成，為瞭整潔的排版及舒適的閱讀，對於模糊不清晰的圖片及黑白圖片進行重新繪制成瞭高清彩圖。

一、消息隊列

1. 消息隊列的介紹

消息（Message）是指在應用之間傳送的數據，消息可以非常簡單，比如隻包含文本字符串，也可以更復雜，可能包含嵌入對象。消息隊列（Message Queue）是一種應用間的通信方式，消息發送後可以立即返回，有消息系統來確保信息的可靠專遞，消息發佈者隻管把消息發佈到MQ中而不管誰來取，消息使用者隻管從MQ中取消息而不管誰發佈的，這樣發佈者和使用者都不用知道對方的存在。

2. 消息隊列的應用場景

消息隊列在實際應用中包括如下四個場景：

• 應用耦合：多應用間通過消息隊列對同一消息進行處理，避免調用接口失敗導致整個過程失敗；
• 異步處理：多應用對消息隊列中同一消息進行處理，應用間並發處理消息，相比串行處理，減少處理時間；
• 限流削峰：廣泛應用於秒殺或搶購活動中，避免流量過大導致應用系統掛掉的情況；
• 消息驅動的系統：系統分為消息隊列、消息生產者、消息消費者，生產者負責產生消息，消費者(可能有多個)負責對消息進行處理；

下面詳細介紹上述四個場景以及消息隊列如何在上述四個場景中使用：

1. 異步處理

具體場景：用戶為瞭使用某個應用，進行註冊，系統需要發送註冊郵件並驗證短信。對這兩個操作的處理方式有兩種：串行及並行。

• 串行方式：新註冊信息生成後，先發送註冊郵件，再發送驗證短信；

在這種方式下，需要最終發送驗證短信後再返回給客戶端。

• 並行處理：新註冊信息寫入後，由發短信和發郵件並行處理；

在這種方式下，發短信和發郵件 需處理完成後再返回給客戶端。假設以上三個子系統處理的時間均為50ms，且不考慮網絡延遲，則總的處理時間：串行：50+50+50=150ms並行：50+50 = 100ms

• 若使用消息隊列：

在寫入消息隊列後立即返回成功給客戶端，則總的響應時間依賴於寫入消息隊列的時間，而寫入消息隊列的時間本身是可以很快的，基本可以忽略不計，因此總的處理時間相比串行提高瞭2倍，相比並行提高瞭一倍；

1. 應用耦合

具體場景：用戶使用QQ相冊上傳一張圖片，人臉識別系統會對該圖片進行人臉識別，一般的做法是，服務器接收到圖片後，圖片上傳系統立即調用人臉識別系統，調用完成後再返回成功，如下圖所示：

該方法有如下缺點：

• 人臉識別系統被調失敗，導致圖片上傳失敗；
• 延遲高，需要人臉識別系統處理完成後，再返回給客戶端，即使用戶並不需要立即知道結果；
• 圖片上傳系統與人臉識別系統之間互相調用，需要做耦合；

若使用消息隊列：

客戶端上傳圖片後，圖片上傳系統將圖片信息如uin、批次寫入消息隊列，直接返回成功；而人臉識別系統則定時從消息隊列中取數據，完成對新增圖片的識別。

此時圖片上傳系統並不需要關心人臉識別系統是否對這些圖片信息的處理、以及何時對這些圖片信息進行處理。事實上，由於用戶並不需要立即知道人臉識別結果，人臉識別系統可以選擇不同的調度策略，按照閑時、忙時、正常時間，對隊列中的圖片信息進行處理。

1. 限流削峰

具體場景：購物網站開展秒殺活動，一般由於瞬時訪問量過大，服務器接收過大，會導致流量暴增，相關系統無法處理請求甚至崩潰。而加入消息隊列後，系統可以從消息隊列中取數據，相當於消息隊列做瞭一次緩沖。

該方法有如下優點：

• 請求先入消息隊列，而不是由業務處理系統直接處理，做瞭一次緩沖,極大地減少瞭業務處理系統的壓力；
• 隊列長度可以做限制，事實上，秒殺時，後入隊列的用戶無法秒殺到商品，這些請求可以直接被拋棄，返回活動已結束或商品已售完信息；

4.消息驅動的系統

具體場景：用戶新上傳瞭一批照片，人臉識別系統需要對這個用戶的所有照片進行聚類，聚類完成後由對賬系統重新生成用戶的人臉索引(加快查詢)。這三個子系統間由消息隊列連接起來，前一個階段的處理結果放入隊列中，後一個階段從隊列中獲取消息繼續處理。

該方法有如下優點：

• 避免瞭直接調用下一個系統導致當前系統失敗；
• 每個子系統對於消息的處理方式可以更為靈活，可以選擇收到消息時就處理，可以選擇定時處理，也可以劃分時間段按不同處理速度處理；

3. 消息隊列的兩種模式

消息隊列包括兩種模式，點對點模式（point to point， queue）和發佈/訂閱模式（publish/subscribe，topic）

1) 點對點模式

點對點模式下包括三個角色：

• 消息隊列
• 發送者 (生產者)
• 接收者（消費者）

消息發送者生產消息發送到queue中，然後消息接收者從queue中取出並且消費消息。消息被消費以後，queue中不再有存儲，所以消息接收者不可能消費到已經被消費的消息。

點對點模式特點：

• 每個消息隻有一個接收者（Consumer）(即一旦被消費，消息就不再在消息隊列中)；
• 發送者和接發收者間沒有依賴性，發送者發送消息之後，不管有沒有接收者在運行，都不會影響到發送者下次發送消息；
• 接收者在成功接收消息之後需向隊列應答成功，以便消息隊列刪除當前接收的消息；

2) 發佈/訂閱模式

發佈/訂閱模式下包括三個角色：

• 角色主題（Topic）
• 發佈者(Publisher)
• 訂閱者(Subscriber)

發佈者將消息發送到Topic，系統將這些消息傳遞給多個訂閱者。

發佈/訂閱模式特點：

• 每個消息可以有多個訂閱者；
• 發佈者和訂閱者之間有時間上的依賴性。針對某個主題（Topic）的訂閱者，它必須創建一個訂閱者之後，才能消費發佈者的消息。
• 為瞭消費消息，訂閱者需要提前訂閱該角色主題，並保持在線運行；

4. 常用的消息隊列介紹

1) RabbitMQ

RabbitMQ 2007年發佈，是一個在AMQP(高級消息隊列協議)基礎上完成的，可復用的企業消息系統，是當前最主流的消息中間件之一。

2) ActiveMQ

ActiveMQ是由Apache出品，ActiveMQ 是一個完全支持JMS1.1和J2EE 1.4規范的 JMS Provider實現。它非常快速，支持多種語言的客戶端和協議，而且可以非常容易的嵌入到企業的應用環境中，並有許多高級功能。

3) RocketMQ

RocketMQ出自 阿裡公司的開源產品，用 Java 語言實現，在設計時參考瞭 Kafka，並做出瞭自己的一些改進，消息可靠性上比 Kafka 更好。RocketMQ在阿裡集團被廣泛應用在訂單，交易，充值，流計算，消息推送，日志流式處理等。

4) Kafka

Apache Kafka是一個分佈式消息發佈訂閱系統。它最初由LinkedIn公司基於獨特的設計實現為一個分佈式的提交日志系統( a distributed commit log)，，之後成為Apache項目的一部分。Kafka系統快速、可擴展並且可持久化。它的分區特性，可復制和可容錯都是其不錯的特性。

5. Pulsar

Apahce Pulasr是一個企業級的發佈-訂閱消息系統，最初是由雅虎開發，是下一代雲原生分佈式消息流平臺，集消息、存儲、輕量化函數式計算為一體，采用計算與存儲分離架構設計，支持多租戶、持久化存儲、多機房跨區域數據復制，具有強一致性、高吞吐、低延時及高可擴展性等流數據存儲特性。

Pulsar 非常靈活：它既可以應用於像 Kafka 這樣的分佈式日志應用場景，也可以應用於像 RabbitMQ 這樣的純消息傳遞系統場景。它支持多種類型的訂閱、多種交付保證、保留策略以及處理模式演變的方法，以及其他諸多特性。

1. Pulsar 的特性

• 內置多租戶：不同的團隊可以使用相同的集群並將其隔離，解決瞭許多管理難題。它支持隔離、身份驗證、授權和配額；
• 多層體系結構：Pulsar 將所有 topic 數據存儲在由 Apache BookKeeper 支持的專業數據層中。存儲和消息傳遞的分離解決瞭擴展、重新平衡和維護集群的許多問題。它還提高瞭可靠性，幾乎不可能丟失數據。另外，在讀取數據時可以直連 BookKeeper，且不影響實時攝取。例如，可以使用 Presto 對 topic 執行 SQL 查詢，類似於 KSQL，但不會影響實時數據處理；
• 虛擬 topic：由於采用 n 層體系結構，因此對 topic 的數量沒有限制，topic 及其存儲是分離的。用戶還可以創建非持久性 topic；
• N 層存儲：Kafka 的一個問題是，存儲費用可能變高。因此，它很少用於存儲"冷"數據，並且消息經常被刪除，Apache Pulsar 可以借助分層存儲自動將舊數據卸載到 Amazon S3 或其他數據存儲系統，並且仍然向客戶端展示透明視圖；Pulsar 客戶端可以從時間開始節點讀取，就像所有消息都存在於日志中一樣；

2. Pulsar 存儲架構

Pulsar 的多層架構影響瞭存儲數據的方式。Pulsar 將 topic 分區劃分為分片（segment），然後將這些分片存儲在 Apache BookKeeper 的存儲節點上，以提高性能、可伸縮性和可用性。

Pulsar 的無限分佈式日志以分片為中心，借助擴展日志存儲（通過 Apache BookKeeper）實現，內置分層存儲支持，因此分片可以均勻地分佈在存儲節點上。由於與任一給定 topic 相關的數據都不會與特定存儲節點進行捆綁，因此很容易替換存儲節點或縮擴容。另外，集群中最小或最慢的節點也不會成為存儲或帶寬的短板。

Pulsar 架構能實現分區管理，負載均衡，因此使用 Pulsar 能夠快速擴展並達到高可用。這兩點至關重要，所以 Pulsar 非常適合用來構建關鍵任務服務，如金融應用場景的計費平臺，電子商務和零售商的交易處理系統，金融機構的實時風險控制系統等。

通過性能強大的 Netty 架構，數據從 producers 到 broker，再到 bookie 的轉移都是零拷貝，不會生成副本。這一特性對所有流應用場景都非常友好，因為數據直接通過網絡或磁盤進行傳輸，沒有任何性能損失。

3. Pulsar 消息消費

Pulsar 的消費模型采用瞭流拉取的方式。流拉取是長輪詢的改進版，不僅實現瞭單個調用和請求之間的零等待，還可以提供雙向消息流。通過流拉取模型，Pulsar 實現瞭端到端的低延遲，這種低延遲比所有現有的長輪詢消息系統（如 Kafka）都低。

6. Kafka與Pulsar對比

1. Pulsar 的主要優勢：

• 更多功能：Pulsar Function、多租戶、Schema registry、n 層存儲、多種消費模式和持久性模式等；
• 更大的靈活性：3 種訂閱類型（獨占，共享和故障轉移），用戶可以在一個訂閱上管理多個 topic；
• 易於操作運維：架構解耦和 n 層存儲；
• 與 Presto 的 SQL 集成，可直接查詢存儲而不會影響 broker；
• 借助 n 層自動存儲選項，可以更低成本地存儲；

2. Pulsar 的劣勢

Pulsar 並不完美，Pulsar 也存在一些問題：

• 相對缺乏支持、文檔和案例；
• n 層體系結構導致需要更多組件：BookKeeper；
• 插件和客戶端相對 Kafka 較少;
• 雲中的支持較少，Confluent 具有托管雲產品。

3. 什麼時候應該考慮 Pulsar

• 同時需要像 RabbitMQ 這樣的隊列和 Kafka 這樣的流處理程序；
• 需要易用的地理復制；
• 實現多租戶，並確保每個團隊的訪問權限；
• 需要長時間保留消息，並且不想將其卸載到另一個存儲中；
• 需要高性能，基準測試表明 Pulsar 提供瞭更低的延遲和更高的吞吐量；

總之，Pulsar還比較新，社區不完善，用的企業比較少，網上有價值的討論和問題的解決比較少，遠沒有Kafka生態系統龐大，且用戶量非常龐大，目前Kafka依舊是大數據領域消息隊列的王者！所以我們還是以Kafka為主！

7. 其他消息隊列與Kafka對比

二、Kafka基礎

1. kafka的基本介紹

官網：http://kafka.apache.org/

kafka是最初由linkedin公司開發的，使用scala語言編寫，kafka是一個分佈式，分區的，多副本的，多訂閱者的日志系統（分佈式MQ系統），可以用於搜索日志，監控日志，訪問日志等。

Kafka is a distributed,partitioned,replicated commit logservice。它提供瞭類似於JMS的特性，但是在設計實現上完全不同，此外它並不是JMS規范的實現。kafka對消息保存時根據Topic進行歸類，發送消息者成為Producer,消息接受者成為Consumer,此外kafka集群有多個kafka實例組成，每個實例(server)成為broker。無論是kafka集群，還是producer和consumer都依賴於zookeeper來保證系統可用性集群保存一些meta信息。

2. kafka的好處

• 可靠性：分佈式的，分區，復本和容錯的。
• 可擴展性：kafka消息傳遞系統輕松縮放，無需停機。
• 耐用性：kafka使用分佈式提交日志，這意味著消息會盡可能快速的保存在磁盤上，因此它是持久的。
• 性能：kafka對於發佈和定於消息都具有高吞吐量。即使存儲瞭許多TB的消息，他也爆出穩定的性能。
• kafka非常快：保證零停機和零數據丟失。

3. 分佈式的發佈與訂閱系統

apache kafka是一個分佈式發佈-訂閱消息系統和一個強大的隊列，可以處理大量的數據，並使能夠將消息從一個端點傳遞到另一個端點，kafka適合離線和在線消息消費。kafka消息保留在磁盤上，並在集群內復制以防止數據丟失。kafka構建在zookeeper同步服務之上。它與apache和spark非常好的集成，應用於實時流式數據分析。

4. kafka的主要應用場景

1. 指標分析

kafka 通常用於操作監控數據。這設計聚合來自分佈式應用程序的統計信息， 以產生操作的數據集中反饋

2. 日志聚合解決方法

kafka可用於跨組織從多個服務器收集日志，並使他們以標準的格式提供給多個服務器。

3. 流式處理

流式處理框架（spark，storm，flink）重主題中讀取數據，對齊進行處理，並將處理後的數據寫入新的主題，供 用戶和應用程序使用，kafka的強耐久性在流處理的上下文中也非常的有用。

三、Kafka架構及組件

1. kafka架構

1. 生產者API

允許應用程序發佈記錄流至一個或者多個kafka的主題（topics）。

1. 消費者API

允許應用程序訂閱一個或者多個主題，並處理這些主題接收到的記錄流。

3。StreamsAPI

允許應用程序充當流處理器（stream processor），從一個或者多個主題獲取輸入流，並生產一個輸出流到一個或 者多個主題，能夠有效的變化輸入流為輸出流。

1. ConnectAPI

允許構建和運行可重用的生產者或者消費者，能夠把kafka主題連接到現有的應用程序或數據系統。例如：一個連接到關系數據庫的連接器可能會獲取每個表的變化。

Kafka 架構

註：在Kafka 2.8.0 版本，移除瞭對Zookeeper的依賴，通過KRaft進行自己的集群管理，使用Kafka內部的Quorum控制器來取代ZooKeeper，因此用戶第一次可在完全不需要ZooKeeper的情況下執行Kafka，這不隻節省運算資源，並且也使得Kafka效能更好，還可支持規模更大的集群。

過去Apache ZooKeeper是Kafka這類分佈式系統的關鍵，ZooKeeper扮演協調代理的角色，所有代理服務器啟動時，都會連接到Zookeeper進行註冊，當代理狀態發生變化時，Zookeeper也會儲存這些數據，在過去，ZooKeeper是一個強大的工具，但是畢竟ZooKeeper是一個獨立的軟件，使得Kafka整個系統變得復雜，因此官方決定使用內部Quorum控制器來取代ZooKeeper。

這項工作從去年4月開始，而現在這項工作取得部分成果，用戶將可以在2.8版本，在沒有ZooKeeper的情況下執行Kafka，官方稱這項功能為Kafka Raft元數據模式（KRaft）。在KRaft模式，過去由Kafka控制器和ZooKeeper所操作的元數據，將合並到這個新的Quorum控制器，並且在Kafka集群內部執行，當然，如果使用者有特殊使用情境，Quorum控制器也可以在專用的硬件上執行。

好，說完在新版本中移除zookeeper這個事，咱們在接著聊kafka的其他功能：

kafka支持消息持久化，消費端是主動拉取數據，消費狀態和訂閱關系由客戶端負責維護，消息消費完後，不會立即刪除，會保留歷史消息。因此支持多訂閱時，消息隻會存儲一份就可以。

1. broker：kafka集群中包含一個或者多個服務實例（節點），這種服務實例被稱為broker（一個broker就是一個節點/一個服務器）；
2. topic：每條發佈到kafka集群的消息都屬於某個類別，這個類別就叫做topic；
3. partition：partition是一個物理上的概念，每個topic包含一個或者多個partition；
4. segment：一個partition當中存在多個segment文件段，每個segment分為兩部分，.log文件和 .index 文件，其中 .index 文件是索引文件，主要用於快速查詢， .log 文件當中數據的偏移量位置；
5. producer：消息的生產者，負責發佈消息到 kafka 的 broker 中；
6. consumer：消息的消費者，向 kafka 的 broker 中讀取消息的客戶端；
7. consumer group：消費者組，每一個 consumer 屬於一個特定的 consumer group（可以為每個consumer指定 groupName）；
8. .log：存放數據文件；
9. .index：存放.log文件的索引數據。

2. Kafka 主要組件

1. producer（生產者）

producer主要是用於生產消息，是kafka當中的消息生產者，生產的消息通過topic進行歸類，保存到kafka的broker裡面去。

2. topic（主題）

1. kafka將消息以topic為單位進行歸類；
2. topic特指kafka處理的消息源（feeds of messages）的不同分類；
3. topic是一種分類或者發佈的一些列記錄的名義上的名字。kafka主題始終是支持多用戶訂閱的；也就是說，一 個主題可以有零個，一個或者多個消費者訂閱寫入的數據；
4. 在kafka集群中，可以有無數的主題；
5. 生產者和消費者消費數據一般以主題為單位。更細粒度可以到分區級別。

3. partition（分區）

kafka當中，topic是消息的歸類，一個topic可以有多個分區（partition），每個分區保存部分topic的數據，所有的partition當中的數據全部合並起來，就是一個topic當中的所有的數據。

一個broker服務下，可以創建多個分區，broker數與分區數沒有關系；在kafka中，每一個分區會有一個編號：編號從0開始。每一個分區內的數據是有序的，但全局的數據不能保證是有序的。（有序是指生產什麼樣順序，消費時也是什麼樣的順序）

4. consumer（消費者）

consumer是kafka當中的消費者，主要用於消費kafka當中的數據，消費者一定是歸屬於某個消費組中的。

5. consumer group（消費者組）

消費者組由一個或者多個消費者組成，同一個組中的消費者對於同一條消息隻消費一次。

每個消費者都屬於某個消費者組，如果不指定，那麼所有的消費者都屬於默認的組。

每個消費者組都有一個ID，即group ID。組內的所有消費者協調在一起來消費一個訂閱主題( topic)的所有分區(partition)。當然，每個分區隻能由同一個消費組內的一個消費者(consumer)來消費，可以由不同的消費組來消費。

partition數量決定瞭每個consumer group中並發消費者的最大數量。如下圖：

示例 1

如上面左圖所示，如果隻有兩個分區，即使一個組內的消費者有4個，也會有兩個空閑的。如上面右圖所示，有4個分區，每個消費者消費一個分區，並發量達到最大4。

在來看如下一幅圖：

示例 2

如上圖所示，不同的消費者組消費同一個topic，這個topic有4個分區，分佈在兩個節點上。左邊的 消費組1有兩個消費者，每個消費者就要消費兩個分區才能把消息完整的消費完，右邊的 消費組2有四個消費者，每個消費者消費一個分區即可。

總結下kafka中分區與消費組的關系：

消費組：由一個或者多個消費者組成，同一個組中的消費者對於同一條消息隻消費一次。某一個主題下的分區數，對於消費該主題的同一個消費組下的消費者數量，應該小於等於該主題下的分區數。

如：某一個主題有4個分區，那麼消費組中的消費者應該小於等於4，而且最好與分區數成整數倍 1 2 4 這樣。同一個分區下的數據，在同一時刻，不能同一個消費組的不同消費者消費。

總結：分區數越多，同一時間可以有越多的消費者來進行消費，消費數據的速度就會越快，提高消費的性能。

6. partition replicas（分區副本）

kafka 中的分區副本如下圖所示：

kafka 分區副本

副本數（replication-factor）：控制消息保存在幾個broker（服務器）上，一般情況下副本數等於broker的個數。

一個broker服務下，不可以創建多個副本因子。創建主題時，副本因子應該小於等於可用的broker數。

副本因子操作以分區為單位的。每個分區都有各自的主副本和從副本；

主副本叫做leader，從副本叫做 follower（在有多個副本的情況下，kafka會為同一個分區下的所有分區，設定角色關系：一個leader和N個 follower），處於同步狀態的副本叫做in-sync-replicas(ISR);

follower通過拉的方式從leader同步數據。消費者和生產者都是從leader讀寫數據，不與follower交互。

副本因子的作用：讓kafka讀取數據和寫入數據時的可靠性。

副本因子是包含本身，同一個副本因子不能放在同一個broker中。

如果某一個分區有三個副本因子，就算其中一個掛掉，那麼隻會剩下的兩個中，選擇一個leader，但不會在其他的broker中，另啟動一個副本（因為在另一臺啟動的話，存在數據傳遞，隻要在機器之間有數據傳遞，就會長時間占用網絡IO，kafka是一個高吞吐量的消息系統，這個情況不允許發生）所以不會在另一個broker中啟動。

如果所有的副本都掛瞭，生產者如果生產數據到指定分區的話，將寫入不成功。

lsr表示：當前可用的副本。

7. segment文件

一個partition當中由多個segment文件組成，每個segment文件，包含兩部分，一個是 .log 文件，另外一個是 .index 文件，其中 .log 文件包含瞭我們發送的數據存儲，.index 文件，記錄的是我們.log文件的數據索引值，以便於我們加快數據的查詢速度。

索引文件與數據文件的關系

既然它們是一一對應成對出現，必然有關系。索引文件中元數據指向對應數據文件中message的物理偏移地址。

比如索引文件中 3,497 代表：數據文件中的第三個message，它的偏移地址為497。

再來看數據文件中，Message 368772表示：在全局partiton中是第368772個message。

.index 與 .log 對應關系如下：

.index 與 .log

上圖左半部分是索引文件，裡面存儲的是一對一對的key-value，其中key是消息在數據文件（對應的log文件）中的編號，比如“1,3,6,8……”， 分別表示在log文件中的第1條消息、第3條消息、第6條消息、第8條消息……

那麼為什麼在index文件中這些編號不是連續的呢？這是因為index文件中並沒有為數據文件中的每條消息都建立索引，而是采用瞭稀疏存儲的方式，每隔一定字節的數據建立一條索引。這樣避免瞭索引文件占用過多的空間，從而可以將索引文件保留在內存中。但缺點是沒有建立索引的Message也不能一次定位到其在數據文件的位置，從而需要做一次順序掃描，但是這次順序掃描的范圍就很小瞭。

value 代表的是在全局partiton中的第幾個消息。

以索引文件中元數據 3,497 為例，其中3代表在右邊log數據文件中從上到下第3個消息， 497表示該消息的物理偏移地址（位置）為497(也表示在全局partiton表示第497個消息-順序寫入特性)。

log日志目錄及組成kafka在我們指定的log.dir目錄下，會創建一些文件夾；名字是 （主題名字-分區名） 所組成的文件夾。在（主題名字-分區名）的目錄下，會有兩個文件存在，如下所示：