Java猿社區—消費方—手動提交位移
參考：《深入理解Kafka：核心設計與實踐原理》
自動提交位移可能帶來重複消費和消息丟失問題
在 Kafka 中默認的消費位移的提交方式是自動提交，這個由消費者客戶端參數enable.auto.commit 配置，默認值爲 true。當然這個默認的自動提交不是每消費一條消息
就提交一次，而是定期提交，這個定期的週期時間由客戶端參數 auto.commit.interval.ms配置，默認值爲 5 秒，此參數生效的前提是 enable.auto.commit 參數爲 true。
在默認的方式下，消費者每隔 5 秒會將拉取到的每個分區中最大的消息位移進行提交 。 自動位移提交的動作是在 poll（）方法的邏輯裏完成的，在每次真正向服務端發起拉取請求之前會檢
查是否可以進行位移提交，如果可以，那麼就會提交上一次輪詢的位移。
自動提交帶來重複消費和消息丟失的問題：
重複消費： 假設剛剛提交完一次消費位移，然後拉取一批消息進行消費，在下一次自動提交消費位移之前，消費者崩潰了，那麼又得從上一次位移提交的地方重新開始消費，這樣便發生了重複消費的現
象（對於再均衡的情況同樣適用）。我們可以通過減小位移提交的時間間隔來減小重複消息的窗口大小，但這樣並不能避免重複消費的發送，而且也會使位移提交更加頻繁。
消息丟失： 消費方拉取的消息在邏輯處理線程還未處理結束，此時到達了自動提交窗口期，自動提交線程將拉取到的每個分區的最大消息位移進行提交，如果此時消費服務掛掉，消息並未處理結束，就會發生消息丟失。
改自動提交爲手動提交位移
公司在線客服的消息服務之前採用的自動提交方式提交位移，現改爲手動提交位移，主要是爲了防止出現消息丟失現象。
重複消費消息：比如如果出現網絡抖動，位移提交失敗，或出現服務掛掉，位移還未來得及提交，待服務恢復，會將此前已部分消費過的消息重複處理一遍，不過此時需要在業務上需要做到冪等。
在線客服消息落庫冪等：在線客服消息服務主要是消息落庫邏輯，根據生成的唯一分佈式消息id（給消息id建立唯一索引），通過insert ignore在新增數據時做到冪等（分庫分表，通過shardingsphere按照羣組id和發送日期進行路由庫和表，在一定的時間窗口內，可以保障路由到同一庫同一張表中，此時mysql可以保障local唯一索引的效果）。
