先處理消費端的丟失數據和重復消費
這倆種情況都是 消息偏移offset的問題導致的，只是場景不同。
offset位移提交一般有倆種方式，自動位移提交和手動位移提交。用enable.auto.commit這個配置屬性去控制
丟失消息一般是自動提交的問題，所以切換成手動位移提交就可以。手動位移提交分成同步提交和異步提交倆種。具體看下圖。
重復消費的處理
對於消費端消息的重復消費問題，如果消費端拉取了一部分數據，消費完畢后，准備執行手動提交（或自動提交）時，消費者掛掉了！此時offset還未提交呢，那么當服務重啟時，還是會拉取相同的一批數據重復處理！造成消息重復消費
所以可以用redis等工具進行原子性事務操作來處理。
接下來看一下生產者的數據重復和丟失問題
1.數據重復
發送消息如果配置了重試機制，比如由於網絡波動，生產者未得到broker收到了消息的響應，就會觸發重試機制，3秒后再次發送此消息。broker之前已經收到過這個消息，但生產者由於觸發了重試機制，就導致了消息的重復發送。那么broker就會在磁盤緩存多條同樣的消息，消費端從broker拉取消息時，就會造成重復消費。
注意：kafka新版本已經在broker中保證了接收消息的冪等性（比如2.4版本），只需在生產者加上參數 props.put(“enable.idempotence”, true) 即可，默認是false不開啟。
2. 數據丟失
生產者消息丟失
生產者在發送消息時，會有一個ack機制，當ack=0 或者 ack=1時，都可能會丟消息。如下所示：
1.acks=0
表示producer不需要等待任何broker確認收到消息的回復，就可以繼續發送下一條消息。性能最高，但是最容易丟消息。大數據統計報表場景，對性能要求很高，對數據丟失不敏感的情況可以用這種。
2.acks=1
至少要等待leader已經成功將數據寫入本地log，但是不需要等待所有follower是否成功寫入。就可以繼續發送下一條消息。這種情況下，如果follower沒有成功備份數據，而此時leader又掛掉，則消息會丟失。
3.acks=-1或all
這意味着leader需要等待所有備份(min.insync.replicas配置的備份個數)都成功寫入日志，這種策略會保證只要有一個備份存活就不會丟失數據。這是最強的數據保證。一般除非是金融級別，或跟錢打交道的場景才會使用這種配置。當然如果min.insync.replicas配置的是1則也可能丟消息，跟acks=1情況類似