1. Kafka 如何做到高吞吐、低延遲的呢？

這里提下 Kafka 寫數據的大致方式：先寫操作系統的頁緩存（Page Cache）,然后由操作系統自行決定何時刷到磁盤。

因此 Kafka 達到高吞吐、低延遲的原因主要有以下 4 點：

• 頁緩存是在內存中分配的，所以消息寫入的速度很快。
• Kafka 不必和底層的文件系統進行交互，所有繁瑣的 I/O 操作都由操作系統來處理。
• Kafka 采用追加寫的方式，避免了磁盤隨機寫操作。
• 使用以 sendfile 為代表的零拷貝技術提高了讀取數據的效率。

PS: 使用頁緩存而非堆內存還有一個好處，就是當 Kafka broker 的進程崩潰時，堆內存的數據會丟失，但是頁緩存的數據依然存在，重啟 Kafka broker 后可以繼續提供服務。

2. Kafka 的 producer 工作流程？

?

?

封裝為?ProducerRecord?實例

序列化

由 partitioner 確定具體分區

發送到內存緩沖區

由 producer 的一個專屬 I/O 線程去取消息，并將其封裝到一個批次 ，發送給對應分區的 kafka broker

leader 將消息寫入本地 log

followers 從 leader pull 消息，寫入本地 log 后 leader 發送 ACK

leader 收到所有 ISR 中的 replica 的 ACK 后，增加 HW（high watermark，最后 commit 的 offset） 并向 producer 發送 ACK

3. Kafka 的 consumer 工作流程？

連接 ZK 集群，拿到對應 topic 的 partition 信息和 partition 的 leader 的相關信息

連接到對應 leader 對應的 broker

consumer 將自己保存的 offset 發送給 leader

leader 根據 offset 等信息定位到 segment（索引文件和日志文件）

根據索引文件中的內容，定位到日志文件中該偏移量對應的開始位置讀取相應長度的數據并返回給 consumer

4. 重要參數有哪些？

acks

• acks = 0 : 不接收發送結果
• acks = all 或者 -1: 表示發送消息時，不僅要寫入本地日志，還要等待所有副本寫入成功。
• acks = 1: 寫入本地日志即可，是上述二者的折衷方案，也是默認值。

? ?2. retries

• 默認為 0，即不重試，立即失敗。
• 一個大于 0 的值，表示重試次數。

3. buffer.memory

• • 指定 producer 端用于緩存消息的緩沖區的大小，默認 32M；
  • 適當提升該參數值，可以增加一定的吞吐量。

4. batch.size

• • producer 會將發送分區的多條數據封裝在一個 batch 中進行發送，這里的參數指的就是 batch 的大小。
  • 該參數值過小的話，會降低吞吐量，過大的話，會帶來較大的內存壓力。
  • 默認為 16K，建議合理增加該值。

5. 丟失數據的場景？

• consumer 端：不是嚴格意義的丟失，其實只是漏消費了。

設置了?auto.commit.enable=true?，當 consumer fetch 了一些數據但還沒有完全處理掉的時候，剛好到 commit interval 觸發了提交 offset 操作，接著 consumer 掛掉。這時已經fetch的數據還沒有處理完成但已經被commit掉，因此沒有機會再次被處理，數據丟失。

• producer 端：

I/O 線程發送消息之前，producer 崩潰， 則 producer 的內存緩沖區的數據將丟失。

6. producer 端丟失數據如何解決？

• 同步發送，性能差，不推薦。
• 仍然異步發送，通過“無消息丟失配置”（來自胡夕的《Apache Kafka 實戰》）極大降低丟失的可能性：

• • block.on.buffer.full = true 盡管該參數在0.9.0.0已經被標記為“deprecated”，但鑒于它的含義非常直觀，所以這里還是顯式設置它為true，使得producer將一直等待緩沖區直至其變為可用。否則如果producer生產速度過快耗盡了緩沖區，producer將拋出異常
  • acks=all 很好理解，所有follower都響應了才認為消息提交成功，即"committed"
  • retries = MAX 無限重試，直到你意識到出現了問題:)
  • max.in.flight.requests.per.connection = 1 限制客戶端在單個連接上能夠發送的未響應請求的個數。設置此值是1表示kafka broker在響應請求之前client不能再向同一個broker發送請求。注意：設置此參數是為了避免消息亂序
  • 使用KafkaProducer.send(record, callback)而不是send(record)方法 自定義回調邏輯處理消息發送失敗
  • callback邏輯中最好顯式關閉producer：close(0) 注意：設置此參數是為了避免消息亂序
  • unclean.leader.election.enable=false 關閉unclean leader選舉，即不允許非ISR中的副本被選舉為leader，以避免數據丟失
  • replication.factor >= 3 這個完全是個人建議了，參考了Hadoop及業界通用的三備份原則
  • min.insync.replicas > 1 消息至少要被寫入到這么多副本才算成功，也是提升數據持久性的一個參數。與acks配合使用
  • 保證replication.factor > min.insync.replicas 如果兩者相等，當一個副本掛掉了分區也就沒法正常工作了。通常設置replication.factor = min.insync.replicas + 1即可

7. consumer 端丟失數據如何解決？

enable.auto.commit=false?關閉自動提交位移，在消息被完整處理之后再手動提交位移

8. 重復數據的場景？

網絡抖動導致 producer 誤以為發送錯誤，導致重試，從而產生重復數據，可以通過冪等性配置避免。

9. 分區策略（即生產消息時如何選擇哪個具體的分區）？

• 指定了 key ，相同的 key 會被發送到相同的分區；
• 沒有指定 key，通過輪詢保證各個分區上的均勻分配。

10. 亂序的場景？

消息的重試發送。

11. 亂序如何解決？

參數配置?max.in.flight.requests.per.connection = 1?，但同時會限制 producer 未響應請求的數量，即造成在 broker 響應之前，producer 無法再向該 broker 發送數據。

12. 如何選擇 Partiton 的數量？

• 在創建 Topic 的時候可以指定 Partiton 數量，也可以在創建完后手動修改。但 Partiton 數量只能增加不能減少。中途增加 Partiton 會導致各個 Partiton 之間數據量的不平等。
• Partition 的數量直接決定了該 Topic 的并發處理能力。但也并不是越多越好。Partition 的數量對消息延遲性會產生影響。
• 一般建議選擇 Broker Num * Consumer Num?，這樣平均每個 Consumer 會同時讀取 Broker 數目個 Partition ， 這些 Partition 壓力可以平攤到每臺 Broker 上。

13. 可重試的異常情況有哪些？

• 分區的 leader 副本不可用，一般發生再 leader 換屆選舉時。
• controller 當前不可用，一般是 controller 在經歷新一輪的選舉。
• 網絡瞬時故障。

14. controller 的職責有哪些？

在 kafka 集群中，某個 broker 會被選舉承擔特殊的角色，即控制器（controller），用于管理和協調 kafka 集群，具體職責如下：

• 管理副本和分區的狀態
• 更新集群元數據信息
• 創建、刪除 topic
• 分區重分配
• leader 副本選舉
• topic 分區擴展
• broker 加入、退出集群
• 受控關閉
• controller leader 選舉

15. leader 掛了會怎樣？（leader failover）

當 leader 掛了之后，controller 默認會從 ISR 中選擇一個 replica 作為 leader 繼續工作，條件是新 leader 必須有掛掉 leader 的所有數據。

如果為了系統的可用性，而容忍降低數據的一致性的話，可以將?unclean.leader.election.enable = true?，開啟 kafka 的"臟 leader 選舉"。當 ISR 中沒有 replica，則會從 OSR 中選擇一個 replica 作為 leader 繼續響應請求，如此操作提高了 Kafka 的分區容忍度，但是數據一致性降低了。

16. broker 掛了會怎樣？（broker failover）

broker上面有很多 partition 和多個 leader 。因此至少需要處理如下內容：

• 更新該 broker 上所有 follower 的狀態
• 從新給 leader 在該 broker 上的 partition 選舉 leader
• 選舉完成后，要更新 partition 的狀態，比如誰是 leader 等

kafka 集群啟動后，所有的 broker 都會被 controller 監控，一旦有 broker 宕機，ZK 的監聽機制會通知到 controller， controller 拿到掛掉 broker 中所有的 partition，以及它上面的存在的 leader，然后從 partition的 ISR 中選擇一個 follower 作為 leader，更改 partition 的 follower 和 leader 狀態。

17. controller 掛了會怎樣？（controller failover）

• 由于每個 broker 都會在 zookeeper 的 "/controller" 節點注冊 watcher，當 controller 宕機時 zookeeper 中的臨時節點消失
• 所有存活的 broker 收到 fire 的通知，每個 broker 都嘗試創建新的 controller path，只有一個競選成功并當選為 controller。

18. Zookeeper 為 Kafka 做了什么？

管理 broker 與 consumer 的動態加入與離開。（Producer 不需要管理，隨便一臺計算機都可以作為Producer 向 Kakfa Broker 發消息）

觸發負載均衡，當 broker 或 consumer 加入或離開時會觸發負載均衡算法，使得一個 consumer group 內的多個 consumer 的消費負載平衡。（因為一個 comsumer 消費一個或多個partition，一個 partition 只能被一個 consumer 消費）

維護消費關系及每個 partition 的消費信息。

19. Page Cache 帶來的好處。

Linux 總會把系統中還沒被應用使用的內存挪來給 Page Cache，在命令行輸入free，或者?cat /proc/meminfo?，“Cached”的部分就是 Page Cache。

Page Cache 中每個文件是一棵 Radix 樹（又稱 PAT 位樹, 一種多叉搜索樹），節點由 4k 大小的 Page 組成，可以通過文件的偏移量（如 0x1110001）快速定位到某個Page。

當寫操作發生時，它只是將數據寫入 Page Cache 中，并將該頁置上 dirty 標志。

當讀操作發生時，它會首先在 Page Cache 中查找，如果有就直接返回，沒有的話就會從磁盤讀取文件寫入 Page Cache 再讀取。

可見，只要生產者與消費者的速度相差不大，消費者會直接讀取之前生產者寫入Page Cache的數據，大家在內存里完成接力，根本沒有磁盤訪問。

而比起在內存中維護一份消息數據的傳統做法，這既不會重復浪費一倍的內存，Page Cache 又不需要 GC?（可以放心使用60G內存了），而且即使 Kafka 重啟了，Page Cache 還依然在。

總結

以上是生活随笔為你收集整理的kafka常见的问题（具体详细）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。