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,再進行業務邏輯處理）