RabbitMQ消費端冪等性概念及解決方案

使用者對於同一操作發起的一次請求或者多次請求的結果是一致的。

比如資料庫的樂觀鎖,在執行更新操作前,先去資料庫查詢version,然後執行更新語句,以version作為條件,如果執行更新時有其他人先更新了這張表的資料,那麼這個條件就不生效了,也就不會執行操作了,通過這種樂觀鎖的機制來保障冪等性.

消費端實現冪等性，就意味著，我們的訊息永遠不會消費多次，即使我們收到了多條一樣的訊息。

在業務高峰期最容易產生訊息重複消費問題,當con消費完訊息時,在給pro返回ack時由於網路中斷,導致pro未收到確認資訊,該條訊息就會重新傳送並被con消費,但實際上該消費者已成功消費了該條訊息,這就造成了重複消費.

唯一id +指紋碼機制，利用db主鍵去重。

select
count(1
)from t_order 
where id = 唯一id +指紋碼

小結

首先我們需要根據訊息生成乙個全域性唯一id，然後還需要加上乙個指紋碼。這個指紋碼它並不一定是系統去生成的，而是一些外部的規則或者內部的業務規則去拼接，它的目的就是為了保障這次操作是絕對唯一的。

將id + 指紋碼拼接好的值作為資料庫主鍵，就可以進行去重了。即在消費訊息前呢，先去資料庫查詢這條訊息的指紋碼標識是否存在，沒有就執行insert操作，如果有就代表已經被消費了，就不需要管了

需要考慮的問題：

這裡只提用redis的原子性去解決mq冪等性重複消費的問題

mq的冪等性問題根本在於的是生產端未正常接收ack，可能是網路抖動、網路中斷導致

可能的方案

con在消費開始時將 id放入到redis的bitmap中，pro每次生產資料時，從redis的bitmap對應位置若不能取出id，則生產訊息傳送，否則不進行訊息傳送。

但是有人可能會說，萬一con，proredis命令執行失敗了怎麼辦，雖然又出現重複消費又出現redis非正常執行命令的可能性極低，但是萬一呢？

ok，我們可以在redis命令執行失敗時，將訊息落庫，每日用定時器，對這種極特殊的訊息進行處理。