rabbitmq消費者集群情況下，怎么保證同一個訊息只被一個消費者消費
uj5u.com熱心網友回復：
佇列中的訊息應該只會被一臺客戶端消費,但例外情況下可能重新訊息回重新回到佇列,所以客戶端還是要做冪等uj5u.com熱心網友回復：
冪等是用全域id存redis嗎？還是先去資料庫查，有資料就returnuj5u.com熱心網友回復：
做法很多,可以根據業務決定,比如唯一鍵(業務中存在唯一的欄位才行),比如訊息體中丟一個uuid,存到一個做冪等的表中,uuid的欄位做唯一鍵也可以保證重復執行不出問題,利用資料庫事務保證唯一,或者加分布式鎖+特定的查詢來保證只執行一次
第二個可以脫離業務做到通用,其他跟業務強相關
uj5u.com熱心網友回復：
全都是不懂瞎說。。。uj5u.com熱心網友回復：
坐等一個大神給一個準確的答案，而不是亂說uj5u.com熱心網友回復：
你不是topic的話只能被消費一次uj5u.com熱心網友回復：
瞎說?請教下哪里瞎說了
uj5u.com熱心網友回復：
你覺得你這個想法能在生產環境去用嗎，用了訊息就是要減輕資料庫的壓力，存到一個做冪等的表中,uuid的欄位做唯一鍵也可以保證重復執行不出問題,利用資料庫事務保證唯一,
這張表的資料量你考慮過嗎，效率
uj5u.com熱心網友回復：
這張表可以定期清理,并不覺得會有多大資料量,可以單獨做成一個組件,幾乎沒有增加額外的復雜度,你插到業務表,當然可以,但與業務代碼耦合,表也增加了一個額外的欄位和唯一約束,對資料庫的壓力并不見得比單獨成表小,畢竟單獨的表可以清理,可以truncate,你那個不能,表一大,索引維護也是很大成本的.
不同取舍罷了,怎么是瞎說?而且mq是減輕資料庫壓力?在性能上是為了削峰填谷,架構上是解耦,mq并不會減少資料庫操作次數,快取才能大幅度減輕資料庫壓力,當然對資料庫完全沒好處是假的,但作用沒那么明顯罷了
uj5u.com熱心網友回復：
重復消費的問題 我的理解是 開啟手動的ack 不管有多少個消費者監聽佇列 ，只有會有一個消費者拿到，先進先出的原則嘛 我不知道我回答的對的還是錯誤的 請大佬們指正，uj5u.com熱心網友回復：
你所說的是一個很理想的環境，但是你必須要考慮，系統在消費資料期間宕機了或者被重啟了的情況，消費是否加事務這個是看業務的，事務是針對資料庫的，那你是在接收到資料的時候就ACK還是在消費結束前ACK？如果是前者，如何確保ACK之后所有的資料都確實都已經消費了？消費了一半的資料該如何處理？如果是后者，消費時間會不會過長導致ACK超時？超時了會重新進入排隊，這時候如果避免別的端重復消費該資料（這就是冪等防止消費）？
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/108869.html
標籤：Java EE