大家好，這里是 菜農曰，歡迎來到我的頻道。

創(chuàng)新互聯(lián)于2013年成立，先為昌黎等服務建站，昌黎等地企業(yè)，進行企業(yè)商務咨詢服務。為昌黎企業(yè)網站制作PC+手機+微官網三網同步一站式服務解決您的所有建站問題。

充滿寒氣的互聯(lián)網如何在面試中脫穎而出，平時積累很重要，八股文更不能少！下面帶來的這篇 Kafka 問答希望能夠在你的 offer 上增添一把🔥。

Kafka最初是由Linkedin公司開發(fā)的，是一個分布式的、可擴展的、容錯的、支持分區(qū)的（Partition）、多副本的（replica）、基于Zookeeper框架的發(fā)布-訂閱消息系統(tǒng)，Kafka適合離線和在線消息消費。它是分布式應用系統(tǒng)中的重要組件之一，也被廣泛應用于大數據處理。Kafka是用Scala語言開發(fā)，它的Java版本稱為Jafka。Linkedin于2010年將該系統(tǒng)貢獻給了Apache基金會并成為頂級開源項目之一。

Kafka 是個大家伙，本篇將通過40道問答作為路線，由淺入深，大程度上覆蓋整個 Kafka 的問答內容（預習＋復習一步到位）

---

1、Kafka 的設計

Kafka 將消息以 topic 為單位進行歸納，發(fā)布消息的程序稱為 Producer，消費消息的程序稱為 Consumer。它是以集群的方式運行，可以由一個或多個服務組成，每個服務叫做一個 Broker，Producer 通過網絡將消息發(fā)送到 kafka 集群，集群向消費者提供消息，broker 在中間起到一個代理保存消息的中轉站。

Kafka 中重要的組件

1）Producer： 消息生產者，發(fā)布消息到Kafka集群的終端或服務

2）Broker：一個 Kafka 節(jié)點就是一個 Broker，多個Broker可組成一個Kafka 集群。

如果某個 Topic 下有 n 個Partition 且集群有 n 個Broker，那么每個 Broker會存儲該 Topic 下的一個 Partition

如果某個 Topic 下有 n 個Partition 且集群中有 m+n 個Broker，那么只有 n 個Broker會存儲該Topic下的一個 Partition

如果某個 Topic 下有 n 個Partition 且集群中的Broker數量小于 n，那么一個 Broker 會存儲該 Topic 下的一個或多個 Partition，這種情況盡量避免，會導致集群數據不均衡

3）Topic：消息主題，每條發(fā)布到Kafka集群的消息都會歸集于此，Kafka是面向Topic 的

4）Partition：Partition 是Topic在物理上的分區(qū)，一個Topic可以分為多個Partition，每個Partition是一個有序的不可變的記錄序列。單一主題中的分區(qū)有序，但無法保證主題中所有分區(qū)的消息有序。

5）Consumer：從Kafka集群中消費消息的終端或服務

6）Consumer Group：每個Consumer都屬于一個Consumer Group，每條消息只能被Consumer Group中的一個Consumer消費，但可以被多個Consumer Group消費。

7）Replica：Partition 的副本，用來保障Partition的高可用性。

8）Controller：Kafka 集群中的其中一個服務器，用來進行Leader election以及各種 Failover 操作。

9）Zookeeper：Kafka 通過Zookeeper來存儲集群中的 meta 消息

2、Kafka 性能高原因

1. 利用了 PageCache 緩存
2. 磁盤順序寫
3. 零拷貝技術
4. pull 拉模式

3、Kafka 文件高效存儲設計原理

1. Kafka把Topic中一個Partition大文件分成多個小文件段，通過多個小文件段，就容易定期清除或刪除已經消費完成的文件，減少磁盤占用
2. 通過索引信息可以快速定位Message和確定response的大大小
3. 通過將索引元數據全部映射到 memory，可以避免 Segment 文件的磁盤I/O操作
4. 通過索引文件稀疏存儲，可以大幅降低索引文件元數據占用空間大小

4、Kafka 的優(yōu)缺點

優(yōu)點

• 高性能、高吞吐量、低延遲：Kafka 生產和消費消息的速度都達到每秒10萬級
• 高可用：所有消息持久化存儲到磁盤，并支持數據備份防止數據丟失
• 高并發(fā)：支持數千個客戶端同時讀寫
• 容錯性：允許集群中節(jié)點失?。ㄈ舾北緮盗繛閚，則允許 n-1 個節(jié)點失敗）
• 高擴展性：Kafka 集群支持熱伸縮，無須停機

缺點

• 沒有完整的監(jiān)控工具集
• 不支持通配符主題選擇

5、Kafka 的應用場景

1. 日志聚合：可收集各種服務的日志寫入kafka的消息隊列進行存儲
2. 消息系統(tǒng)：廣泛用于消息中間件
3. 系統(tǒng)解耦：在重要操作完成后，發(fā)送消息，由別的服務系統(tǒng)來完成其他操作
4. 流量削峰：一般用于秒殺或搶購活動中，來緩沖網站短時間內高流量帶來的壓力
5. 異步處理：通過異步處理機制，可以把一個消息放入隊列中，但不立即處理它，在需要的時候在進行處理

6、Kafka 中分區(qū)的概念

主題是一個邏輯上的概念，還可以細分為多個分區(qū)，一個分區(qū)只屬于單個主題，很多時候也會把分區(qū)稱為主題分區(qū)（Topic-Partition）。同一主題下的不同分區(qū)包含的消息是不同的，分區(qū)在存儲層面可以看做一個可追加的日志文件，消息在被追加到分區(qū)日志文件的時候都會分配一個特定的偏移量（offset）。offset 是消息在分區(qū)中的唯一標識，kafka 通過它來保證消息在分區(qū)內的順序性，不過 offset 并不跨越分區(qū)，也就是說，kafka保證的是分區(qū)有序而不是主題有序。

在分區(qū)中又引入了多副本（replica）的概念，通過增加副本數量可以提高容災能力。同一分區(qū)的不同副本中保存的是相同的消息。副本之間是一主多從的關系，其中主副本負責讀寫，從副本只負責消息同步。副本處于不同的 broker 中，當主副本出現(xiàn)異常，便會在從副本中提升一個為主副本。

7、Kafka 中分區(qū)的原則

1. 指明Partition的情況下，直接將指明的值作為Partition值
2. 沒有指明Partition值但有 key 的情況下，將 key 的 Hash 值與 topic 的Partition值進行取余得到Partition值
3. 既沒有Partition值又沒有 key 值的情況下，第一次調用時隨機生成一個整數（后面每次調用在這個整數上自增），將這個值與Topic可用的Partition總數取余得到Parittion值，也就是常說的 round-robin 算法

8、Kafka 為什么要把消息分區(qū)

1. 方便在集群中擴展，每個 Partition 可用通過調整以適應它所在的機器，而一個Topic又可以有多個Partition組成，因此整個集群就可以適應任意大小的數據了
2. 可以提高并發(fā)，因為可以以Partition為單位進行讀寫

9、Kafka 中生產者運行流程

1. 一條消息發(fā)過來首先會被封裝成一個 ProducerRecord 對象
2. 對該對象進行序列化處理（可以使用默認，也可以自定義序列化）
3. 對消息進行分區(qū)處理，分區(qū)的時候需要獲取集群的元數據，決定這個消息會被發(fā)送到哪個主題的哪個分區(qū)
4. 分好區(qū)的消息不會直接發(fā)送到服務端，而是放入生產者的緩存區(qū)，多條消息會被封裝成一個批次（Batch），默認一個批次的大小是 16KB
5. Sender 線程啟動以后會從緩存里面去獲取可以發(fā)送的批次
6. Sender 線程把一個一個批次發(fā)送到服務端

10、Kafka 中的消息封裝

在Kafka 中 Producer 可以 Batch的方式推送數據達到提高效率的作用。Kafka Producer 可以將消息在內存中累積到一定數量后作為一個 Batch 發(fā)送請求。Batch 的數量大小可以通過 Producer 的參數進行控制，可以從三個維度進行控制

• 累計的消息的數量（如500條）
• 累計的時間間隔（如100ms）
• 累計的數據大?。ㄈ?4KB）

通過增加 Batch 的大小，可以減少網絡請求和磁盤I/O的頻次，具體參數配置需要在效率和時效性做一個權衡。

11、Kafka 消息的消費模式

Kafka采用大部分消息系統(tǒng)遵循的傳統(tǒng)模式：Producer將消息推送到Broker，Consumer從Broker獲取消息。

如果采用 Push 模式，則Consumer難以處理不同速率的上游推送消息。

采用 Pull 模式的好處是Consumer可以自主決定是否批量的從Broker拉取數據。Pull模式有個缺點是，如果Broker沒有可供消費的消息，將導致Consumer不斷在循環(huán)中輪詢，直到新消息到達。為了避免這點，Kafka有個參數可以讓Consumer阻塞直到新消息到達。

12、Kafka 如何實現(xiàn)負載均衡與故障轉移

負載均衡是指讓系統(tǒng)的負載根據一定的規(guī)則均衡地分配在所有參與工作的服務器上，從而大限度保證系統(tǒng)整體運行效率與穩(wěn)定性

負載均衡

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

故障轉移

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

13、Kafka 中 Zookeeper 的作用

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

14、Kafka 提供了哪些系統(tǒng)工具

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

15、Kafka 中消費者與消費者組的關系與負載均衡實現(xiàn)

Consumer Group 是Kafka獨有的可擴展且具有容錯性的消費者機制。一個組內可以有多個Consumer，它們共享一個全局唯一的Group ID。組內的所有Consumer協(xié)調在一起來消費訂閱主題（Topic）內的所有分區(qū)（Partition）。當然，每個Partition只能由同一個Consumer Group內的一個Consumer 來消費。消費組內的消費者可以使用多線程的方式實現(xiàn)，消費者的數量通常不超過分區(qū)的數量，且二者最好保持整數倍的關系，這樣不會造成有空閑的消費者。

Consumer 訂閱的是Topic的Partition，而不是Message。所以在同一時間點上，訂閱到同一個分區(qū)的Consumer必然屬于不同的Consumer Group

Consumer Group與Consumer的關系是動態(tài)維護的，當一個Consumer進程掛掉或者是卡住時，該Consumer所訂閱的Partition會被重新分配到改組內的其他Consumer上，當一個Consumer加入到一個Consumer Group中時，同樣會從其他的Consumer中分配出一個或者多個Partition到這個新加入的Consumer。

負載均衡

當啟動一個Consumer時，會指定它要加入的Group，使用的配置項是：Group.id

為了維持Consumer與Consumer Group之間的關系，Consumer 會周期性地發(fā)送 hearbeat 到 coodinator（協(xié)調者），如果有 hearbeat 超時或未收到 hearbeat，coordinator 會認為該Consumer已經退出，那么它所訂閱的Partition會分配到同一組內的其他Consumer上，這個過程稱為 rebalance（再平衡）

16、Kafka 中消息偏移的作用

生產過程中給分區(qū)中的消息提供一個順序ID號，稱之為偏移量，偏移量的主要作用為了唯一地區(qū)別分區(qū)中的每條消息。Kafka的存儲文件都是按照offset.kafka來命名

17、 生產過程中何時會發(fā)生QueueFullExpection以及如何處理

何時發(fā)生

當生產者試圖發(fā)送消息的速度快于Broker可以處理的速度時，通常會發(fā)生 QueueFullException

如何解決

首先先進行判斷生產者是否能夠降低生產速率，如果生產者不能阻止這種情況，為了處理增加的負載，用戶需要添加足夠的 Broker。或者選擇生產阻塞，設置Queue.enQueueTimeout.ms為 -1，通過這樣處理，如果隊列已滿的情況，生產者將組織而不是刪除消息?；蛘呷萑踢@種異常，進行消息丟棄。

18、Consumer 如何消費指定分區(qū)消息

Cosumer 消費消息時，想Broker 發(fā)出fetch請求去消費特定分區(qū)的消息，Consumer 可以通過指定消息在日志中的偏移量 offset，就可以從這個位置開始消息消息，Consumer 擁有了 offset 的控制權，也可以向后回滾去重新消費之前的消息。

也可以使用seek(Long topicPartition)來指定消費的位置。

19、Replica、Leader 和 Follower 三者的概念

Kafka 中的 Partition 是有序消息日志，為了實現(xiàn)高可用性，需要采用備份機制，將相同的數據復制到多個Broker上，而這些備份日志就是 Replica，目的是為了 防止數據丟失。

所有Partition 的副本默認情況下都會均勻地分布到所有 Broker 上,一旦領導者副本所在的Broker宕機，Kafka 會從追隨者副本中選舉出新的領導者繼續(xù)提供服務。

Leader： 副本中的領導者。負責對外提供服務，與客戶端進行交互。生產者總是向 Leader副本些消息，消費者總是從 Leader 讀消息

Follower： 副本中的追隨者。被動地追隨 Leader，不能與外界進行交付。只是向Leader發(fā)送消息，請求Leader把最新生產的消息發(fā)給它，進而保持同步。

20、Replica 的重要性

Replica 可以確保發(fā)布的消息不會丟失，保證了Kafka的高可用性。并且可以在發(fā)生任何機器錯誤、程序錯誤或軟件升級、擴容時都能生產使用。

21、Kafka 中的 Geo-Replication 是什么

Kafka官方提供了MirrorMaker組件，作為跨集群的流數據同步方案。借助MirrorMaker，消息可以跨多個數據中心或云區(qū)域進行復制。您可以在主動/被動場景中將其用于備份和恢復，或者在主動/主動方案中將數據放置得更靠近用戶，或支持數據本地化要求。

它的實現(xiàn)原理比較簡單，就是通過從源集群消費消息，然后將消息生產到目標集群，即普通的消息生產和消費。用戶只要通過簡單的Consumer配置和Producer配置，然后啟動Mirror，就可以實現(xiàn)集群之間的準實時的數據同步.

22、Kafka 中 AR、ISR、OSR 三者的概念

• AR：分區(qū)中所有副本稱為 AR
• ISR：所有與主副本保持一定程度同步的副本（包括主副本）稱為 ISR
• OSR：與主副本滯后過多的副本組成 OSR

23、分區(qū)副本什么情況下會從 ISR 中剔出

Leader 會維護一個與自己基本保持同步的Replica列表，該列表稱為ISR，每個Partition都會有一個ISR，而且是由Leader動態(tài)維護。所謂動態(tài)維護，就是說如果一個Follower比一個Leader落后太多，或者超過一定時間未發(fā)起數據復制請求，則Leader將其從ISR中移除。當ISR中所有Replica都向Leader發(fā)送ACK（Acknowledgement確認）時，Leader才commit。

24、分區(qū)副本中的 Leader 如果宕機但 ISR 卻為空該如何處理

可以通過配置unclean.leader.election：

• true：允許 OSR 成為 Leader，但是 OSR 的消息較為滯后，可能會出現(xiàn)消息不一致的問題
• false：會一直等待舊 leader 恢復正常，降低了可用性

25、如何判斷一個 Broker 是否還有效

1. Broker必須可以維護和ZooKeeper的連接，Zookeeper通過心跳機制檢查每個結點的連接。
2. 如果Broker是個Follower，它必須能及時同步Leader的寫操作，延時不能太久。

26、Kafka 可接收的消息大默認多少字節(jié)，如何修改

Kafka可以接收的大消息默認為1000000字節(jié)，如果想調整它的大小，可在Broker中修改配置參數：Message.max.bytes的值

但要注意的是，修改這個值，還要同時注意其他對應的參數值是正確的，否則就可能引發(fā)一些系統(tǒng)異常。首先這個值要比消費端的fetch.Message.max.bytes（默認值1MB，表示消費者能讀取的大消息的字節(jié)數）參數值要小才是正確的設置，否則Broker就會因為消費端無法使用這個消息而掛起。

27、Kafka 的 ACK 機制

Kafka的Producer有三種ack機制，參數值有0、1 和 -1

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

28、Kafka 的 consumer 如何消費數據

在Kafka中，Producers將消息推送給Broker端，在Consumer和Broker建立連接之后，會主動去 Pull（或者說Fetch）消息。這種模式有些優(yōu)點，首先Consumer端可以根據自己的消費能力適時的去fetch消息并處理，且可以控制消息消費的進度（offset）；此外，消費者可以控制每次消費的數，實現(xiàn)批量消費。

29、Kafka 提供的API有哪些

Kafka 提供了兩套 Consumer API，分為 High-level API 和 Sample API

Sample API

這是一個底層API，它維持了一個與單一 Broker 的連接，并且這個API 是完全無狀態(tài)的，每次請求都需要指定 offset 值，因此這套 API 也是最靈活的。

High-level API

該API封裝了對集群中一系列Broker的訪問，可以透明地消費下一個Topic，它自己維護了已消費消息的狀態(tài)，即每次消費的都會下一個消息。High-level API 還支持以組的形式消費Topic，如果 Consumers 有同一個組名，那么Kafka就相當于一個隊列消息服務，而各個 Consumer 均衡地消費相應Partition中的數據。若Consumers有不同的組名，那么此時Kafka就相當于一個廣播服務，會把Topic中的所有消息廣播到每個Consumer

30、Kafka 的Topic中 Partition 數據是怎么存儲到磁盤的

Topic 中的多個 Partition 以文件夾的形式保存到 Broker，每個分區(qū)序號從0遞增，且消息有序。Partition 文件下有多個Segment（xxx.index，xxx.log），Segment文件里的大小和配置文件大小一致。默認為1GB，但可以根據實際需要修改。如果大小大于1GB時，會滾動一個新的Segment并且以上一個Segment最后一條消息的偏移量命名。

31、Kafka 創(chuàng)建Topic后如何將分區(qū)放置到不同的 Broker 中

Kafka創(chuàng)建Topic將分區(qū)放置到不同的Broker時遵循以下規(guī)則：

1. 副本因子不能大于Broker的個數。
2. 第一個分區(qū)（編號為0）的第一個副本放置位置是隨機從Broker List中選擇的。
3. 其他分區(qū)的第一個副本放置位置相對于第0個分區(qū)依次往后移。也就是如果有3個Broker，3個分區(qū)，假設第一個分區(qū)放在第二個Broker上，那么第二個分區(qū)將會放在第三個Broker上；第三個分區(qū)將會放在第一個Broker上，更多Broker與更多分區(qū)依此類推。剩余的副本相對于第一個副本放置位置其實是由nextReplicaShift決定的，而這個數也是隨機產生的。

32、Kafka 的日志保留期與數據清理策略

概念

保留期內保留了Kafka群集中的所有已發(fā)布消息，超過保期的數據將被按清理策略進行清理。默認保留時間是7天，如果想修改時間，在server.properties里更改參數log.retention.hours/minutes/ms的值便可。

清理策略

• 刪除：log.cleanup.policy=delete表示啟用刪除策略，這也是默認策略。一開始只是標記為delete，文件無法被索引。只有過了log.Segment.delete.delay.ms這個參數設置的時間，才會真正被刪除。
• 壓縮：log.cleanup.policy=compact表示啟用壓縮策略，將數據壓縮，只保留每個Key最后一個版本的數據。首先在Broker的配置中設置log.cleaner.enable=true啟用 cleaner，這個默認是關閉的。

33、Kafka 日志存儲的Message是什么格式

Kafka一個Message由固定長度的header和一個變長的消息體body組成。將Message存儲在日志時采用不同于Producer發(fā)送的消息格式。每個日志文件都是一個log entries（日志項）序列：

1. 每一個log entry包含一個四字節(jié)整型數（Message長度，值為1+4+N）。
2. 1個字節(jié)的magic，magic表示本次發(fā)布Kafka服務程序協(xié)議版本號。
3. 4個字節(jié)的CRC32值，CRC32用于校驗Message。
4. 最終是N個字節(jié)的消息數據。每條消息都有一個當前Partition下唯一的64位offset。

Kafka沒有限定單個消息的大小，但一般推薦消息大小不要超過1MB，通常一般消息大小都在1～10KB之間。

34、Kafka 是否支持多租戶隔離

多租戶技術（multi-tenancy technology）是一種軟件架構技術，它是實現(xiàn)如何在多用戶的環(huán)境下共用相同的系統(tǒng)或程序組件，并且仍可確保各用戶間數據的隔離性。

解決方案

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

35、Kafka 的日志分段策略與刷新策略

日志分段（Segment）策略

1. log.roll.hours/ms：日志滾動的周期時間，到達指定周期時間時，強制生成一個新的Segment，默認值168h（7day）。
2. log.Segment.bytes：每個Segment的大容量。到達指定容量時，將強制生成一個新的Segment。默認值1GB（-1代表不限制）。
3. log.retention.check.interval.ms：日志片段文件檢查的周期時間。默認值60000ms。

日志刷新策略

Kafka的日志實際上是開始是在緩存中的，然后根據實際參數配置的策略定期一批一批寫入到日志文件中，以提高吞吐量。

1. log.flush.interval.Messages：消息達到多少條時將數據寫入到日志文件。默認值為10000。
2. log.flush.interval.ms：當達到該時間時，強制執(zhí)行一次flush。默認值為null。
3. log.flush.scheduler.interval.ms：周期性檢查，是否需要將信息flush。默認為很大的值。

36、Kafka 中如何進行主從同步

Kafka動態(tài)維護了一個同步狀態(tài)的副本的集合（a set of In-SyncReplicas），簡稱ISR，在這個集合中的結點都是和Leader保持高度一致的，任何一條消息只有被這個集合中的每個結點讀取并追加到日志中，才會向外部通知“這個消息已經被提交”。

kafka 通過配置producer.type來確定是異步還是同步，默認是同步

同步復制

Producer 會先通過Zookeeper識別到Leader，然后向 Leader 發(fā)送消息，Leader 收到消息后寫入到本地 log文件。這個時候Follower 再向 Leader Pull 消息，Pull 回來的消息會寫入的本地 log 中，寫入完成后會向 Leader 發(fā)送 Ack 回執(zhí)，等到 Leader 收到所有 Follower 的回執(zhí)之后，才會向 Producer 回傳 Ack。

異步復制

Kafka 中 Producer 異步發(fā)送消息是基于同步發(fā)送消息的接口來實現(xiàn)的，異步發(fā)送消息的實現(xiàn)很簡單，客戶端消息發(fā)送過來以后，會先放入一個BlackingQueue隊列中然后就返回了。Producer 再開啟一個線程ProducerSendTread不斷從隊列中取出消息，然后調用同步發(fā)送消息的接口將消息發(fā)送給 Broker。

Producer的這種在內存緩存消息，當累計達到閥值時批量發(fā)送請求，小數據I/O太多，會拖慢整體的網絡延遲，批量延遲發(fā)送事實上提升了網絡效率。但是如果在達到閥值前，Producer不可用了，緩存的數據將會丟失。

37、Kafka 中什么情況下會出現(xiàn)消息丟失/不一致的問題

消息發(fā)送時

消息發(fā)送有兩種方式：同步 - sync和異步 - async。默認是同步的方式，可以通過 producer.type 屬性進行配置，kafka 也可以通過配置 acks 屬性來確認消息的生產

• 0：表示不進行消息接收是否成功的確認
• 1：表示當 leader 接收成功時的確認
• -1：表示 leader 和 follower 都接收成功的確認

當 acks = 0 時，不和 Kafka 進行消息接收確認，可能會因為網絡異常，緩沖區(qū)滿的問題，導致消息丟失

當 acks = 1 時，只有 leader 同步成功而 follower 尚未完成同步，如果 leader 掛了，就會造成數據丟失

消息消費時

Kafka 有兩個消息消費的 consumer 接口，分別是low-level和hign-level

1. low-level：消費者自己維護 offset 等值，可以實現(xiàn)對 kafka 的完全控制
2. high-level：封裝了對 partition 和 offset，使用簡單

如果使用高級接口，可能存在一個消費者提取了一個消息后便提交了 offset，那么還沒來得及消費就已經掛了，下次消費時的數據就是 offset + 1 的位置，那么原先 offset 的數據就丟失了。

38、Kafka 作為流處理平臺的特點

流處理就是連續(xù)、實時、并發(fā)和以逐條記錄的方式處理數據的意思。Kafka 是一個分布式流處理平臺，它的高吞吐量、低延時、高可靠性、容錯性、高可擴展性都使得Kafka非常適合作為流式平臺。

1. 它是一個簡單的、輕量級的Java類庫，能夠被集成到任何Java應用中
2. 除了Kafka之外沒有任何其他的依賴，利用Kafka的分區(qū)模型支持水平擴容和保證順序性
3. 支持本地狀態(tài)容錯，可以執(zhí)行非?？焖儆行У挠袪顟B(tài)操作
4. 支持 eexactly-once 語義
5. 支持一次處理一條記錄，實現(xiàn) ms 級的延遲

39、消費者故障，出現(xiàn)活鎖問題如何解決

活鎖的概念：消費者持續(xù)的維持心跳，但沒有進行消息處理。

為了預防消費者在這種情況一直持有分區(qū)，通常會利用max.poll.interval.ms活躍檢測機制，如果調用 Poll 的頻率大于大間隔，那么消費者將會主動離開消費組，以便其他消費者接管該分區(qū)

40、Kafa 中如何保證順序消費

Kafka 的消費單元是 Partition，同一個 Partition 使用 offset 作為唯一標識保證順序性，但這只是保證了在 Partition 內部的順序性而不是 Topic 中的順序，因此我們需要將所有消息發(fā)往統(tǒng)一 Partition 才能保證消息順序消費，那么可以在發(fā)送的時候指定 MessageKey，同一個 key 的消息會發(fā)到同一個 Partition 中。

---

以上便是本篇的全部內容，不要空談，不要貪懶，和小菜一起做個吹著牛X做架構的程序猿吧~點個關注做個伴，讓小菜不再孤單。咱們下文見！

今天的你多努力一點，明天的你就能少說一句求人的話！

我是小菜，一個和你一起變強的男人。💋

微信公眾號已開啟，菜農曰，沒關注的同學們記得關注哦！

你是否還在尋找穩(wěn)定的海外服務器提供商？創(chuàng)新互聯(lián)www.cdcxhl.cn海外機房具備T級流量清洗系統(tǒng)配攻擊溯源，準確流量調度確保服務器高可用性，企業(yè)級服務器適合批量采購，新人活動首月15元起，快前往官網查看詳情吧

本文名稱：刨根問底Kafka，面試過程真好使-創(chuàng)新互聯(lián)
URL分享：http://weahome.cn/article/hjege.html