kafka重複消費原因
底層根本原因：已經消費了資料，但是offset沒提交。
原因1：強行kill執行緒，導致消費後的資料，offset沒有提交。
原因2：設定offset為自動提交，關閉kafka時，如果在close之前，呼叫
consumer.unsubscribe() 則有可能部分offset沒提交，下次重啟會重複消費。例如：
try catch (exception e) catch (exception e) {
上面**會導致部分offset沒提交，下次啟動時會重複消費。
kafka consumer丟失資料原因
猜測：設定offset為自動定時提交，當offset被自動定時提交時，資料還在記憶體中未處理，此時剛好把執行緒kill掉，那麼offset已經提交，但是資料未處理，導致這部分記憶體中的資料丟失。
記錄offset和恢復offset的方案
理論上記錄offset，下乙個group consumer可以接著記錄的offset位置繼續消費。
offset記錄方案：
每次消費時更新每個topic+partition位置的offset在記憶體中，
map，key=topic+'-'+partition，value=offset
當呼叫關閉consumer執行緒時，把上面map的offset資料記錄到 檔案中*（分布式集群可能要記錄到redis中）。
然後使用consumer.seek()方法指定到上次的offset位置。
說明：1、該方案針對單台伺服器比較簡單，直接把offset記錄到本地檔案中即可，但是對於多台伺服器集群，offset也要記錄到同乙個地方，並且需要做去重處理。
如果線上程式是由多台伺服器組成的集群，是否可以用一台伺服器來支撐？應該可以，只是消費慢一點，沒多大影響。
2、如何保證接著offset消費的資料正確性
為了確保consumer消費的資料一定是接著上一次consumer消費的資料，
consumer消費時，記錄第一次取出的資料，將其offset和上次consumer最後消費的offset進行對比，如果相同則繼續消費。如果不同，則停止消費，檢查原因。
Kafka重複消費，不丟失資料
kafka0.11.0.0版本正式支援精確一次處理語義exactly once semantic eos kafka冪等性參考 1 冪等producer 保證單個分割槽的只會傳送一次，不會出現重複訊息 2 事務 transation 保證原子性的寫入多個分割槽，即寫入到多個分割槽的訊息要麼全部成功，...
kafka丟失和重複消費資料
kafka作為當下流行的高併發訊息中介軟體，大量用於資料採集，實時處理等場景，我們在享受他的高併發，高可靠時，還是不得不面對可能存在的問題，最常見的就是丟包，重發問題。1 丟包問題 訊息推送服務，每天早上，手機上各終端都會給使用者推送訊息，這時候流量劇增，可能會出現kafka傳送資料過快，導致伺服器...
Kafka 訊息丟失和訊息重複消費
producer 的acks引數值設定為 0 或者 1 不等待伺服器確認或者只讓leader確認解決方法 將acks的值設定為all或者 1，讓leader和followers全部進行確認 producer 沒有設定失敗重試解決方法 根據實際場景將retries引數值設定為正整數 consumerp...