1:如果消費者進行消費的時候出現失敗，佇列會進行重試機制
因為底層使用的rabbitlistener aop 進行攔截，如果出現了異常自動實現補償機制，該訊息會儲存到rabbitmq伺服器進行存放，直到一直不丟擲異常為準。
如果程式沒有丟擲異常，則進行提交 事務
2:進行修改重試機制---一般五秒 消費者
如果重試了五次還不行則放棄這個訊息，重試間隔是3秒的時間
佇列裡面之前快取的
mq的重試機制需要注意的問題
程式** 發生異常的訊息 進行記錄日誌 ，然後定時救補 自動進行補償，獲取人工介面進行補償
三：如何保證mq的消費者冪等性問題 重複消費問題
使用全域性id判斷是否是同乙個
保證全域性id唯一，如果消費過了，就不讓他消費，在生產者進行頭中攜帶唯一id
rabbitmq的應答模式：自動應答和手動應答【ack模式】
1：需要在消費者一端
重試機制預設是一直重試，如果我們設定了五次的話，我們不能直接給他丟了，而是放到死信佇列裡面去
五：rabbitmq的死信佇列
生產者投遞到交換機 然後通過路由key 投遞到具體的佇列中。
如果具體的佇列中已經滿了，如果生產者還要投遞訊息 會出現訊息丟失問題， 佇列已經滿了會產生丟失資料問題，因為佇列已經滿了已經到了極限了，如何保證資料不丟失呢，可以設定過期時間，如果規定時間沒有消費完 佇列可以把他刪除掉
也就是說當佇列已經滿了，或者已經補償次數限制到了 然後就放到死信佇列
六：rabbitmq解決分布式事務【mq解決最終一致性問題】
手動重試 注意冪等性問題、
場景1：如果生產者投遞訊息到佇列中，但是消費者消費訊息失敗了，用手動ack補償機制，但是要注意冪等性問題，防止重複消費
場景2：如果生產者傳送訊息到mq伺服器失敗了呢，如何保證生產者傳送訊息到mq伺服器成功
解決辦法：使用生產者的重試機制進行傳送訊息，通過confirm機制（確認機制）
1：實現這個類
2：重寫方法
生產者往mq伺服器端傳送訊息的時候採用應答機制，如果 ack 為true 為成功
傳送失敗，然後重新進行傳送給伺服器端
生產者補償也是有最大的次數限制的，可以配置，超過限制就有問題了，如果超過限制了還不行，那只能做人工配置了
4：開啟生產者確認機制
場景三：生產者傳送投遞訊息到佇列中成功了，消費者也已經消費了，但是生產者出現異常 然後進行回滾了。
這個時候我們需要使用到補單機制 進行補單，如果出現異常了就是回滾了，然後補單佇列進行補單，補單消費者進行消費
十 RabbitMQ 冪等性
目錄使用者對於同一操作發起的一次請求或者多次請求的結果是一致的，不會因為多次點選而產生了 舉個最簡單的例子，那就是支付，使用者購買商品後支付，支付扣款成功，但是返回結果的時候網路異常，此時錢已經扣了，使用者再次點選按鈕，此時會進行第二次扣款，返回結果成功，使用者查詢餘額發現多扣錢了，流水記錄也變成了...
RabbitMQ 冪等性概念及業界主流解決方案
可以參考資料庫樂觀鎖機制，比如執行一條更新庫存的 sql 語句，在併發場景，為了效能和資料可靠性，會在更新時加上查詢時的版本，並且更新這個版本資訊。可能你要對乙個事情進行操作，這個操作可能會執行成百上千次，但是操作結果都是相同的，這就是冪等性。在海量訂單生成的業務高峰期，生產端有可能就會重 生了訊息...
冪等性的實現
1.生成key的方式 記得保證redis生成的key和刪除的key是成功的 看返回值 1 允許表單跳轉 這種情況比較容易，比如在列表中新增一條記錄，可以在列表頁面生成乙個key，放到redis中，同時在新增頁面時帶著這個key。等到提交時，把key也提交，後台根據key與redis中進行比較，有的話...