冪等性：乙個請求，不管重複來多少次，結果是不會改變的。
每個訊息都會有唯一的訊息 id。
1）、先查再儲存
每次儲存資料的時候，都先查一下，如果資料存在了那麼就不儲存。這個情況是併發不高的情況。
2）、業務表新增約束條件
如果你的資料庫將來都不會分庫分表，那麼可以在業務表字段加上唯一約束條件（unique），這樣相同的資料就不會儲存為多份。
3）、新增訊息表
再資料庫裡面，新增一張訊息消費記錄表，表字段加上唯一約束條件（unique），消費完之後就往表裡插入一條資料。因為加了唯一約束條件，第二次儲存的時候，mysql 就會報錯，就插入不進去；通過資料庫可以限制重複消費。
4）、使用 redis
如果你的系統是分布式的，又做了分庫分表，那麼可以使用 redis 來做記錄，把訊息 id 存在 redis 裡，下次再有重複訊息 id 在消費的時候，如果發現 redis 裡面有了就不能進行消費。
5）、高併發下
如果你的系統併發很高，那麼可以使用 redis 或者 zookeeper 的分布式對訊息 id 加鎖，然後使用上面的幾個方法進行冪等性控制
kafka消費訊息時的冪等性
1.什麼是kafka消費訊息時的冪等性 kafka消費訊息時的冪等性，簡而言之就是消費者對介面的多次呼叫所產生的結果和呼叫一次是是一致的，也就是說在kafka中有可能會消費到重複的資料，這個時候需要客戶端去處理這種情況，使得訊息消費一次和消費多次是一樣的結果。2.產生原因 資料流 生產者 生產者會往...
訊息佇列三 訊息重複消費問題（冪等性）
其實這個很常見的乙個問題，這倆問題基本可以連起來問。既然是消費訊息，那肯定要考慮考慮會不會重複消費？能不能避免重複消費？或者重複消費了也別造成系統異常可以嗎？這個是mq領域的基本問題，其實本質上還是問你使用訊息佇列如何保證冪等性，這個是你架構裡要考慮的乙個問題。要考慮的實際生產上的系統設計問題。首先...
訊息冪等 如何保證訊息不被重複消費？
應用的冪等是在分布式系統設計時必須要考慮的乙個方面，如果對冪等沒有額外的考慮，那麼在訊息失敗重新投遞，或者遠端服務重試時，可能會出現許多詭異的問題。一起來看一下，在訊息佇列應用中，如何處理因為重複投遞等原因導致的冪等問題。不同訊息佇列支援的投遞方式 業務上如何處理冪等 首先明確一下，冪等並不是問題，...