1at most once 至多一次：乙個訊息只被消費一次，不管是否成功，允許丟失一部分訊息。
2at least once至少一次：一條訊息會被重複消費
3exactly once恰好一次：一條訊息只被處理一次，且必須成功，不能夠失敗
大部分訊息佇列都是符合 at least once, 如rabbitmq ，rocketmq ，允許出現重複訊息。
在有重複訊息的前提下，新增冪等可以保證系統的穩定，保證訊息不被消費。
冪等可以通過幾種方式來實現：
1.採用資料庫唯一約束來實現。例如redis的setnx ，資料庫的唯一索引約束，在進行業務邏輯之前去查詢，是否進行下面邏輯。
2為更新資料之前新增條件，比如：只有餘額等於100的時候才去更新，
3記錄並檢查。為每條訊息乙個唯一標識，並提供是否被消費的標識，在消費時去校驗是否已經被消費，但這樣為增加系統的複雜性，為每條訊息提供唯一標識就不是一件簡單的事情，而且檢查狀態，更新資料，更新消費狀態，必須符合原子性。
訊息佇列如何處理重複訊息
一 訊息重複現象 在 mqtt 協議中，給出了三種傳遞訊息時能夠提供的服務質量標準 at most once 最多一次，這種情況會丟失部分資料，一般日誌收集這種對資料不嚴格的可以使用 at least once 最少一次，這種會導致一條訊息重 送 exactly once 正好一次，一條訊息只會被消...
電商場景下，如何處理消費過程中的重複訊息？
摘要 比如乙個消費訂單訊息，統計下單金額的微服務。若不正確處理重複訊息，就會出現重複統計。那僅靠mq能保證訊息不重複嗎？訊息傳遞過程中若失敗，則傳送方會執行重試，重試就可能產生重複訊息。若不處理重複訊息，可能收穫驚喜。比如乙個消費訂單訊息，統計下單金額的微服務。若不正確處理重複訊息，就會出現重複統計...
如何保證訊息不被重複消費
如何保證訊息不被重複消費啊 如何保證訊息消費時的冪等性 首先就是比如rabbitmq rocketmq kafka，都有可能會出現消費重複消費的問題，正常。因為這問題通常不是mq自己保證的，是給你保證的。然後我們挑乙個kafka來舉個例子，說說怎麼重複消費吧。kafka實際上有個offset的概念，...