kafka作為當下流行的高併發訊息中介軟體，大量用於資料採集，實時處理等場景，我們在享受他的高併發，高可靠時，還是不得不面對可能存在的問題，最常見的就是丟包，重發問題。
1、丟包問題：訊息推送服務，每天早上，手機上各終端都會給使用者推送訊息，這時候流量劇增，可能會出現kafka傳送資料過快，導致伺服器網絡卡爆滿，或者磁碟處於繁忙狀態，可能會出現丟包現象。
解決方案：首先對kafka進行限速， 其次啟用重試機制，重試間隔時間設定長一些，最後kafka設定acks=all，即需要相應的所有處於isr的分割槽都確認收到該訊息後，才算傳送成功。
檢測方法：使用重放機制，檢視問題所在。
kafka配置如下：
props.put("compression.type", "gzip");
props.put("linger.ms", "50");
props.put("acks", "all");
props.put("retries ", 30);
props.put("reconnect.backoff.ms ", 20000);
props.put("retry.backoff.ms", 20000);
2、重發問題：當消費者重新分配partition的時候，可能出現從頭開始消費的情況，導致重發問題。當消費者消費的速度很慢的時候，可能在乙個session週期內還未完成，導致心跳機制檢測報告出問題。
底層根本原因：已經消費了資料，但是offset沒提交。
配置問題：設定了offset自動提交
解決辦法：至少發一次+去重操作（冪等性）
問題場景：
設定offset為自動提交，正在消費資料，kill消費者執行緒；
設定offset為自動提交，關閉kafka時，如果在close之前，呼叫 consumer.unsubscribe() 則有可能部分offset沒提交，下次重啟會重複消費；
消費kafka與業務邏輯在乙個執行緒中處理，可能出現消費程式業務處理邏輯阻塞超時，導致乙個週期內，offset還未提交；繼而重複消費，但是業務邏輯可能採用傳送kafka或者其他無法回滾的方式；
重複消費最常見的原因：re-balance問題,通常會遇到消費的資料，處理很耗時，導致超過了kafka的session timeout時間（0.10.x版本預設是30秒），那麼就會re-balance重平衡，此時有一定機率offset沒提交，會導致重平衡後重複消費。
3、去重問題：訊息可以使用唯一id標識
保證不丟失訊息：生產者（ack=all 代表至少成功傳送一次)
消費者 （offset手動提交，業務邏輯成功處理後，提交offset）
保證不重複消費：落表（主鍵或者唯一索引的方式，避免重複資料）
業務邏輯處理（選擇唯一主鍵儲存到redis或者mongdb中，先查詢是否存在，若存在則不處理；若不存在，先插入redis或mongdb,再進行業務邏輯處理）
Kafka 訊息丟失和訊息重複消費
producer 的acks引數值設定為 0 或者 1 不等待伺服器確認或者只讓leader確認解決方法 將acks的值設定為all或者 1，讓leader和followers全部進行確認 producer 沒有設定失敗重試解決方法 根據實際場景將retries引數值設定為正整數 consumerp...
Kafka 訊息丟失和訊息重複消費
producer 的acks引數值設定為 0 或者 1 不等待伺服器確認或者只讓leader確認解決方法 將acks的值設定為all或者 1，讓leader和followers全部進行確認 producer 沒有設定失敗重試解決方法 根據實際場景將retries引數值設定為正整數 consumerp...
Kafka生產消費資料丟失和優化小結
我們經常會遇到kafka資料丟失的問題，所以將遇到過的或有可能造成資料丟失的問題進行個小總結。其實在kafka處理資料的流程有很多，把這些流程梳理一遍，有助於分析資料丟失的情況，從這個圖中可以看出資料流向，圖中涉及的所以過程都可能造成資料的丟失。首先要確定是否有業務資料寫入 再明確資料是在kafka...