面試官：聊一聊 kafka 線上會遇到哪些問題？

1、哪些環(huán)節(jié)會造成消息丟失？

首先說說哪些環(huán)節(jié)會丟消息

消息生產者：

（1）acks=0：表示producer不需要等待任何broker確認收到消息的回復，就可以繼續(xù)發(fā)送下一條消息。性能最高，但是最容易丟消 息。大數(shù)據(jù)統(tǒng)計報表場景，對性能要求很高，對數(shù)據(jù)丟失不敏感的情況可以用這種。

（2）acks=1：至少要等待leader已經(jīng)成功將數(shù)據(jù)寫入本地log，但是不需要等待所有follower是否成功寫入。就可以繼續(xù)發(fā)送下一條消 息。這種情況下，如果follower沒有成功備份數(shù)據(jù)，而此時leader又掛掉，則消息會丟失。

（3）acks=-1或all：這意味著leader需要等待所有備份(min.insync.replicas配置的備份個數(shù))都成功寫入日志，這種策略會保證只要有一 個備份存活就不會丟失數(shù)據(jù)。這是最強的數(shù)據(jù)保證。一般除非是金融級別，或跟錢打交道的場景才會使用這種配置。當然如果 min.insync.replicas配置的是1則也可能丟消息，跟acks=1情況類似。

消息消費端：

如果消費這邊配置的是自動提交，萬一消費到數(shù)據(jù)還沒處理完，就自動提交offset了，但是此時你consumer直接宕機了，未處理完的數(shù)據(jù) 丟失了，下次也消費不到了。

怎么保證消息不丟失？

生產端：消息發(fā)送+回調

偽代碼

消費端：業(yè)務處理完后手動提交事務

最新 Kafka?面試題整理好了，點擊Java面試庫小程序在線刷題。

2、消息重復消費

消息發(fā)送端：

發(fā)送消息如果配置了重試機制，比如網(wǎng)絡抖動時間過長導致發(fā)送端發(fā)送超時，實際broker可能已經(jīng)接收到消息，但發(fā)送方會重新發(fā)送消息

消息消費端：

如果消費這邊配置的是自動提交，剛拉取了一批數(shù)據(jù)處理了一部分，但還沒來得及提交，服務掛了，下次重啟又會拉取相同的一批數(shù)據(jù)重 復處理

一般消費端都是要做消費冪等處理的。

3、消息順序

如果發(fā)送端配置了重試機制，kafka不會等之前那條消息完全發(fā)送成功才去發(fā)送下一條消息，這樣可能會出現(xiàn)，發(fā)送了1，2，3條消息，第 一條超時了，后面兩條發(fā)送成功，再重試發(fā)送第1條消息，這時消息在broker端的順序就是2，3，1了 所以，是否一定要配置重試要根據(jù)業(yè)務情況而定。也可以用同步發(fā)送的模式去發(fā)消息，當然acks不能設置為0，這樣也能保證消息從發(fā)送 端到消費端全鏈路有序。

kafka保證全鏈路消息順序消費，需要從發(fā)送端開始，將所有有序消息發(fā)送到同一個分區(qū)，然后用一個消費者去消費，但是這種性能比較 低，可以在消費者端接收到消息后將需要保證順序消費的幾條消費發(fā)到內存隊列(可以搞多個)，一個內存隊列開啟一個線程順序處理消 息。

4、消息積壓

1）線上有時因為發(fā)送方發(fā)送消息速度過快，或者消費方處理消息過慢，可能會導致broker積壓大量未消費消息。此種情況如果積壓了上百萬未消費消息需要緊急處理，可以修改消費端程序，讓其將收到的消息快速轉發(fā)到其他topic(可以設置很多分 區(qū))，然后再啟動多個消費者同時消費新主題的不同分區(qū)。

2）由于消息數(shù)據(jù)格式變動或消費者程序有bug，導致消費者一直消費不成功，也可能導致broker積壓大量未消費消息。此種情況可以將這些消費不成功的消息轉發(fā)到其它隊列里去(類似死信隊列)，后面再慢慢分析死信隊列里的消息處理問題。

最新 Kafka 面試題整理好了，點擊Java面試庫小程序在線刷題。

5、kafka高性能原因：

?磁盤順序讀寫：kafka消息不能修改以及不會從文件中間刪除保證了磁盤順序讀，kafka的消息寫入文件都是追加在文件末尾， 不會寫入文件中的某個位置(隨機寫)保證了磁盤順序寫。

?數(shù)據(jù)傳輸?shù)牧憧截?/p>

?讀寫數(shù)據(jù)的批量batch處理以及壓縮傳輸

傳統(tǒng)文件復制方式：需要對文件在內存中進行四次拷貝。

零拷貝：有兩種方式， mmap和transfile

Java當中對零拷貝進行了封裝， Mmap方式通過MappedByteBuffer對象進行操作，而transfile通過FileChannel來進行操作。

Mmap 適合比較小的文件，通常文件大小不要超過1.5G ~2G 之間。

Transfile沒有文件大小限制

在kafka當中，他的index日志文件也是通過mmap的方式來讀寫的。在其他日志文件當中，并沒有使用零拷貝的方式。

kafka使用transfile方式將硬盤數(shù)據(jù)加載到網(wǎng)卡。

獲取 Spring Boot 實戰(zhàn)筆記！