1.問題背景
某服務（用了springboot + spring-kafka）處理kafka訊息時，發現每條訊息處理時間長達60+秒。幾百條訊息處理完後，又重新從第一條開始重複消費。
2.原因分析
kafka消費者有兩個配置引數：
max.poll.interval.ms
兩次poll操作允許的最大時間間隔。單位毫秒。預設值300000（5分鐘）。
兩次poll超過此時間間隔，kafka服務端會進行rebalance操作，導致客戶端連線失效，無法提交offset資訊，從而引發重複消費。
max.poll.records
一次poll操作獲取的訊息數量。預設值50。
如果每條訊息處理時間超過60秒，那麼一批訊息處理時間將超過5分鐘，從而引發poll超時，最終導致重複消費。
3.對策分析
1）分析業務**邏輯，進行效能優化，確保每條訊息處理時間控制在合理範圍
每條訊息的處理時間不要超過5分鐘。
如果超過5分鐘，則考慮進行架構上的優化。
比如a執行緒消費訊息，放到程序內部佇列中，提交offset；其他執行緒從內部佇列取訊息，並處理業務邏輯。為防止內部佇列訊息積壓，a執行緒需要監控佇列中訊息數量，超過一定量時進入等待。
2）適當增大max.poll.interval.ms的值
springboot沒有提供可調節此數值的引數。如果修改此數值，需要自己封裝方法建立kafka客戶端：
org.apache.kafka.clients.consumer.kafkaconsumer.kafkaconsumer(properties)
MQ順序消費解決方案
1.順序錯亂的常見原因 訊息傳送 多執行緒並行傳送，有順序的訊息被寫入到不同的分割槽，異常重試。訊息消費 多消費者並行消費，或消費者內部啟用多執行緒消費。異常重試。2.為什麼要保證訊息的順序 如果業務上通過訊息傳送的資料是有前後順序關係時，則必須保證訊息的順序。例如 通過mq同步資料時，如果增 改 ...
MQ中保證訊息不被重複消費解決方案
在網路延遲傳輸中，會造成進行mq的訊息重試，在重試的過程中，可能會引用訊息的重發消費 在客戶端 中，由於程式設計師大意，訊息沒有簽收，或者事務沒有提交等，都會有可能造成重發消費 方案一 如果訊息是做資料庫的插入操作，那個給這個訊息做個唯一主鍵，那麼就散出現重複消費的情況，就會導致主鍵衝突，避免資料庫...
佇列訊息重複消費解決
其實這個很常見的乙個問題，這倆問題基本可以連起來問。既然是消費訊息，那肯定要考慮考慮會不會重複消費？能不能避免重複消費？或者重複消費了也別造成系統異常可以嗎？這個是mq領域的基本問題，其實本質上還是問你使用訊息佇列如何保證冪等性，這個是你架構裡要考慮的乙個問題。要考慮的實際生產上的系統設計問題。首先...