RabbitMQ 死信隊列

文章目錄

• 死信隊列的作用
• 如何配置死信隊列
• 樣例

死信隊列的作用

  使用 RabbitMQ 的時候可能會碰到以下幾個問題：

1. 消費者端調用了

   basicNack

   或者

   basicReject

   ，并且沒有進行

   requeue

   ，如果沒做其他措施的話，這個消息也就丢失了。
2. 消息在隊列的存活時間超過設定的

   TTL

   時間。
3. 消息隊列的消息數量已經超過最大隊列長度。

  以上幾個問題都會導緻消息丢失，消息丢失的代價可大可小，視自己業務情況而定，有些業務如果消息丢失無所謂的話就不用理睬，相信大部分業務都是不允許丢失的。

死信隊列

的出現就可以解決以上三個問題，當以上三個問題出現時，消息不會丢失，會重新放入死信隊列，至于如何處理死信隊列中的消息就看自己公司的業務了。

如何配置死信隊列

  死信隊列其實本身也是普通的隊列，隻是在邏輯上賦予了它特殊的含義，需要綁定對應的死信交換機，與隊列概念一樣，也是普通的交換機，賦予了

死信

的含義。那麼整體流程如下：

1. 建立死信交換機

   

2. 建立死信隊列

   

3. 在死信交換機中綁定死信隊列與死信交換機

   

4. 建立業務交換機

   

5. 建立業務隊列并

   關聯

   死信交換機與死信隊列

   

6. 在業務交換機中綁定業務隊列與業務交換機

   

以上操作可以在 Web 上操作，亦可在項目中用代碼實作。

  步驟 5 中的

x-dead-letter-exchange

指定死信交換機、

x-dead-letter-routing-key

指定路由到指定 Queue 的路由 key，一般配置跟 Queue 一樣。

  一般情況下會為每一個業務隊列都配置一個相對應的死信隊列，也可以多個業務隊列共用一個死信隊列。要注意的是業務隊列和死信隊列的交換機要區分開。

樣例

  配置如下：

spring:
  rabbitmq:
    host: localhost
    port: 5672
    username: admin
    password: 123456
    virtual-host: 'example'
    # 生産者 ==>> Exchange 确認方式
    publisher-confirm-type: correlated
    # Exchange ==>> Queue
    publisher-returns: true
    listener:
      simple:
        # ACK 模式，此處選擇自動 ACK
        acknowledge-mode: auto
        # 每次處理 100 條消息
        prefetch: 100
        # 決定由于監聽器抛出異常而拒絕的消息是否被重新放回隊列。預設值為 true，重新放回隊列。這裡設定為 false，如果多次重試還是異常就轉發到死信隊列
        default-requeue-rejected: false
        retry:
          # 開啟重試
          enabled: true
          # 最大重試 3 次，涵蓋目前次
          max-attempts: 3
          # 每次重試間隔時間
          initial-interval: 3000
          # 最大允許重試間隔時間，用來限制 initial-interval。
          max-interval: 10000
          # 下一次重試的時間間隔 = 上次重試時間間隔 * multiplier
          multiplier: 2
           

  消費者端簡單抛個異常：

  最終都跑到死信隊列了。