昨天業務反饋了乙個問題，乙個使用者的月流水賬單重複了，拿到userid，開始定位問題之路。
檢視資料庫記錄，如下圖，使用者月流水資料確實重複了（taskid同乙個批次，每個月資料都有二條）。
1. 首先，看外部資料**商是否重複推送業務資料給我，我程式中是會設定攔截重複訊息
2. 檢視訊息接收，以及訊息推送到mq
訊息接收
訊息推送
看下來前面的步驟都沒有重複，再看訊息的消費，如下圖所示：
原因定位：看是消費端消費了mq中的同一條訊息消費了二次，這個發生時間正好在我們上線時間，也就是上線的時候會發生訊息重複消費，因為乙個訊息被處理之後，沒來得及提交offset消費執行緒就被kill掉了，然後重啟之後從mq拿的訊息還是之前的訊息，當然好處是保證每條訊息都保證至少會消費一次，缺點是訊息可能會重複消費。
解決方案：1. 對於流程中的訊息，每條訊息中包含唯一id，比如業務id，在資料庫中將業務id作為unique key，插入重複時會報duplicate key異常；
2. redis中儲存業務id，重複的時候set一下，任務丟棄，redis的key失效時間可以設定的很短，因為重複消費的一般發生間隔時間非常短。
訊息冪等 如何保證訊息不被重複消費？
應用的冪等是在分布式系統設計時必須要考慮的乙個方面，如果對冪等沒有額外的考慮，那麼在訊息失敗重新投遞，或者遠端服務重試時，可能會出現許多詭異的問題。一起來看一下，在訊息佇列應用中，如何處理因為重複投遞等原因導致的冪等問題。不同訊息佇列支援的投遞方式 業務上如何處理冪等 首先明確一下，冪等並不是問題，...
訊息佇列三 訊息重複消費問題（冪等性）
其實這個很常見的乙個問題，這倆問題基本可以連起來問。既然是消費訊息，那肯定要考慮考慮會不會重複消費？能不能避免重複消費？或者重複消費了也別造成系統異常可以嗎？這個是mq領域的基本問題，其實本質上還是問你使用訊息佇列如何保證冪等性，這個是你架構裡要考慮的乙個問題。要考慮的實際生產上的系統設計問題。首先...
訊息匯流排真的能保證冪等
一 緣起 如 訊息匯流排訊息必達 所述，mq訊息必達，架構上有兩個核心設計點 1 訊息落地 2 訊息超時 重傳 確認 再次回顧訊息匯流排核心架構，它由傳送端 服務端 固化儲存 接收端四大部分組成。為保證訊息的可達性，超時 重傳 確認機制可能導致訊息匯流排 或者業務方收到重複的訊息，從而對業務產生影響...