RabbitMQ不講武德，發個訊息也這麼多花招

前言

本篇部落格已被收錄GitHub：https://zhouwenxing.github.io/
文中所涉及的原始碼也已被收錄GitHub：https://github.com/zhouwenxing/lonely-wolf-note (message-queue模組)

使用訊息佇列必須要保證生產者傳送的訊息能被消費者所接收，那麼生產者如何接收訊息呢？下圖是 RabbitMQ 的工作模型：

上圖中生產者會將訊息傳送到交換機 Exchange 上，再由 Exchange 傳送給不同的 Queue ，而 Queue 是用來儲存訊息佇列，那麼假如有多個生產者，那麼訊息傳送到交換機 Exchange 之後，應該如何和 Queue 之間建立繫結關係呢?

如何使用 RabbitMQ 傳送訊息

RabbitMQ 中提供了3種傳送訊息的路由方式。

直連 Direct 模式

通過指定一個精確的繫結鍵來實現 Exchange（交換機） 和 Queue（訊息佇列） 之間的繫結，也就是說，當建立了一個直連型別的交換機時，生產者在傳送訊息時攜帶的路由鍵（routing key），必須與某個繫結鍵（binding key）完全匹配時，這條訊息才會從交換機路由到滿足路由關係訊息佇列上，然後消費者根據各自監聽的佇列就可以獲取到訊息（如下如吐所示，Queue1 繫結了 order ，那麼這時候傳送訊息的路由鍵必須為 order 才能分配到 Queue1 上）：

主題 Topic 模式

Direct 模式會存在一定的侷限性，有時候我們需要按型別劃分，比如訂單類路由到一個佇列，產品類路由到另一個佇列，所以在 RabbitMQ 中，提供了主題模式來實現模糊匹配。使用主題型別連線方式支援兩種萬用字元：

直連方式只能精確匹配，有時候我們需要實現模糊匹配，那麼這時候就需要主題型別的連線方式，在 RabbitMQ 中，使用主題型別連線方式支援兩種萬用字元：

• ：表示 0 個或者多個單詞

• *：表示 1 個單詞

PS：使用萬用字元時，單詞指的是用英文符號的小數點 . 隔開的字元，如：abc.def 就表示有 abc 和 def 兩個單詞。

下圖所示中，因為 Queue1 繫結了 order.#，所以當傳送訊息的路由鍵為 order 或者 order.xxx時都可以使得訊息分配到 Queue1 上：

廣播 Fanout 模式

當我們定義了一個廣播型別的交換機時就不需要指定繫結鍵，而且生產者傳送訊息到交換機上時，也不需要攜帶路由鍵，此時當訊息到達交換機時，所有與其繫結的佇列都會收到訊息，這種模式的訊息傳送適用於訊息通知類需求。

如下如所示，Queue1，Queue2，Queue3 三個佇列都繫結到了一個 Fanout 交換機上，那麼當 Fanout Exchange 收到訊息時，會同時將訊息傳送給三個佇列：

在 RabbitMQ 提供的後臺管理系統中也能查詢到建立的交換機和佇列等資訊，並且可以通過管理後臺直接建立佇列和交換機：

訊息傳送實戰

下面通過一個 SpringBoot 例子來體會一下三種傳送訊息的方式。

• 1、application.yml 檔案中新增如下配置：

spring:
  rabbitmq:
    host: ip
    port: 5672
    username: admin
    password: 123456

• 2、新增一個 RabbitConfig 配置類（為了節省篇幅省略了包名和匯入 ），此類中宣告瞭三個交換機和三個佇列，並分別進行繫結：

@Configuration
public class RabbitConfig {
    //直連交換機
    @Bean("directExchange")
    public DirectExchange directExchange(){
        return new DirectExchange("LONGLY_WOLF_DIRECT_EXCHANGE");
    }

    //主題交換機
    @Bean("topicExchange")
    public TopicExchange topicExchange(){
        return new TopicExchange("LONGLY_WOLF_TOPIC_EXCHANGE");
    }

    //廣播交換機
    @Bean("fanoutExchange")
    public FanoutExchange fanoutExchange(){
        return new FanoutExchange("LONGLY_WOLF_FANOUT_EXCHANGE");
    }


    @Bean("orderQueue")
    public Queue orderQueue(){
        return new Queue("LONGLY_WOLF_ORDER_QUEUE");
    }

    @Bean("userQueue")
    public Queue userQueue(){
        return new Queue("LONGLY_WOLF_USER_QUEUE");
    }

    @Bean("productQueue")
    public Queue productQueue(){
        return new Queue("LONGLY_WOLF_PRODUCT_QUEUE");
    }

    //Direct交換機和orderQueue繫結，繫結鍵為：order.detail
    @Bean
    public Binding bindDirectExchange(@Qualifier("orderQueue") Queue queue, @Qualifier("directExchange") DirectExchange directExchange){
        return BindingBuilder.bind(queue).to(directExchange).with("order.detail");
    }

    //Topic交換機和userQueue繫結，繫結鍵為：user.#
    @Bean
    public Binding bindTopicExchange(@Qualifier("userQueue") Queue queue, @Qualifier("topicExchange") TopicExchange topicExchange){
        return BindingBuilder.bind(queue).to(topicExchange).with("user.#");
    }

    //Fanout交換機和productQueue繫結
    @Bean
    public Binding bindFanoutExchange(@Qualifier("productQueue") Queue queue, @Qualifier("fanoutExchange") FanoutExchange fanoutExchange){
        return BindingBuilder.bind(queue).to(fanoutExchange);
    }
}

• 3、新建一個消費者 ExchangeConsumer 類，不同的方法實現分別監聽不同的佇列：

@Component
public class ExchangeConsumer {

    /**
     * 監聽繫結了direct交換機的的訊息佇列
     */
    @RabbitHandler
    @RabbitListener(queues = "LONGLY_WOLF_ORDER_QUEUE")
    public void directConsumer(String msg){
        System.out.println("direct交換機收到訊息：" + msg);
    }

    /**
     * 監聽繫結了topic交換機的的訊息佇列
     */
    @RabbitHandler
    @RabbitListener(queues = "LONGLY_WOLF_USER_QUEUE")
    public void topicConsumer(String msg){
        System.out.println("topic交換機收到訊息：" + msg);
    }

    /**
     * 監聽繫結了fanout交換機的的訊息佇列
     */
    @RabbitHandler
    @RabbitListener(queues = "LONGLY_WOLF_PRODUCT_QUEUE")
    public void fanoutConsumer(String msg){
        System.out.println("fanout交換機收到訊息：" + msg);
    }
}

• 4、新增一個 RabbitExchangeController 類來作為生產者，進行訊息傳送：

@RestController
@RequestMapping("/exchange")
public class RabbitExchangeController {
    @Autowired
    private RabbitTemplate rabbitTemplate;

    @GetMapping(value="/send/direct")
    public String sendDirect(String routingKey,@RequestParam(value = "msg",defaultValue = "no direct message") String msg){
        rabbitTemplate.convertAndSend("LONGLY_WOLF_DIRECT_EXCHANGE",routingKey,msg);
        return "succ";
    }
    @GetMapping(value="/send/topic")
    public String sendTopic(String routingKey,@RequestParam(value = "msg",defaultValue = "no topic message") String msg){
        rabbitTemplate.convertAndSend("LONGLY_WOLF_TOPIC_EXCHANGE",routingKey,msg);
        return "succ";
    }
    @GetMapping(value="/send/fanout")
    public String sendFaout(String routingKey,@RequestParam(value = "msg",defaultValue = "no faout message") String msg){
        rabbitTemplate.convertAndSend("LONGLY_WOLF_FANOUT_EXCHANGE",routingKey,msg);
        return "succ";
    }
}

• 5、啟動服務，當我們呼叫第一個介面時候，路由鍵和繫結鍵 order.detail 精確匹配時，directConsumer 就會收到訊息，同樣的，呼叫第二介面時，路由鍵滿足 user.# 時，topicConsumer 就會收到訊息，而只要呼叫第三個介面，不論是否指定路由鍵，fanoutConsumer 都會收到訊息。

訊息過期了怎麼辦

簡單的傳送訊息我們學會了，難道這就能讓我們就此止步了嗎？顯然是不能的，要玩就要玩高階點，所以接下來讓我們給訊息加點佐料。

TTL（Time-To-Live）

TTL 即 一條訊息在佇列中的最大存活時間。在一條在佇列中超過配置的 TTL 的訊息稱為已死訊息。但是需要注意的是，已死訊息並不能保證會立即從佇列中刪除，但是能保證已死的訊息不會被投遞出去。

設定 TTL 的方式有兩種：

• 1、給佇列設定 x-message-ttl，此時所有被投遞到佇列中的訊息，都會在到達 TTL 時成為已死訊息。

  這種情況就會出現當一條訊息同時路由到 N 個帶有 TTL 時間的佇列，而由於每個佇列的 TTL 不一定相同，所以同一條訊息在不同的佇列中可能會在不同時間死亡或者不會死亡（未設定 TTL ），所以一個佇列中的訊息死亡不會影響到其他佇列中的訊息。

• 2、單獨給某一條訊息設定過期時間。

  此時需要注意的時，當訊息達到 TTL 時，可能不會馬上被丟棄，因為只有處於佇列頭部訊息過期後才會被丟棄，假如佇列頭部的訊息沒有設定 TTL，而第 2 條訊息設定了 TTL，那麼即使第 2 條訊息成為了已死訊息，也必須要等到佇列頭部的訊息被消費之後才會被丟棄，而已死訊息在被丟棄之前也會被計入統計資料（比如佇列中的訊息總數）。所以為了更好的利用 TTL 特性，建議讓消費者線上消費訊息，這樣才能確保訊息更快的被丟棄，防止訊息堆積。

PS：訊息過期和消費者傳遞之間可能存在自然的競爭條件。例如，訊息可能在傳送途中（未到達消費者）過期。

佇列的生存

和 TTL 針對訊息不同的是，我們可以通過設定過期時間屬性 `x-expires`` 來處理佇列，當在指定過期時間內內未使用佇列時，伺服器保證將刪除佇列（但是無法保證在過期時間過後佇列將以多快的速度被刪除）。

TTL 和過期時間實戰

• 1、在上面定義的 RabbitConfig 類中，再新增一個 TTL 佇列並將其繫結到 direct 交換機上：

@Bean("ttlQueue")
public Queue ttlQueue(){
    Map<String, Object> map = new HashMap<String, Object>();
    map.put("x-message-ttl", 5000);//佇列中所有訊息5秒後過期
    map.put("x-expires", 100000);//佇列閒置10秒後被刪除
    //引數1-name：佇列名稱
    //引數2-durable：是否持久化
    //引數3-exclusive:是否排他。設定為true時，則該佇列只對宣告當前佇列的連線(Connection)可用,一旦連線斷開，佇列自動被刪除
    //引數4-autoDelete：是否自動刪除。前提是必須要至少有一個消費者先連上當前佇列，然後當所有消費者都斷開連線之後，佇列自動被刪除
    return new Queue("LONGLY_WOLF_TTL_QUEUE",false,false,false,map);
    }

//ttl佇列繫結到direct交換機（交換機和佇列可以多對多）
@Bean
public Binding ttlBindFanoutExchange(@Qualifier("ttlQueue") Queue queue, @Qualifier("directExchange") DirectExchange directExchange){
    return BindingBuilder.bind(queue).to(directExchange).with("test.ttl");
}

• 2、在 ExchangeConsumer 消費者類上監聽 TTL 佇列（和其他消費者不同的時候，這裡為了列印出佇列屬性，改成了通過 Message 物件來接收訊息 ）：

/**
 * 監聽ttl訊息佇列
*/
@RabbitHandler
@RabbitListener(queues = "LONGLY_WOLF_TTL_QUEUE")
public void ttlConsumer(Message message){
    System.out.println("ttl佇列收到訊息：" + new String(message.getBody()));
    System.out.println("ttl佇列收到訊息：" + JSONObject.toJSONString(message.getMessageProperties()));
}

• 3、在生產者類 RabbitExchangeController 上新增一個介面用來測試傳送過期訊息，這裡通過 MessageProperties 設定的 expiration 屬性就相當於是給單條訊息設定了一個 TTL ：

@GetMapping(value="/send/ttl")
public String sendTtl(String routingKey,@RequestParam(value = "msg",defaultValue = "no ttl message") String msg){
    MessageProperties messageProperties = new MessageProperties();
    messageProperties.setExpiration("5000");//5秒後被刪除，即TTL屬性（針對單條訊息）
    Message message = new Message(msg.getBytes(), messageProperties);
    rabbitTemplate.convertAndSend("LONGLY_WOLF_DIRECT_EXCHANGE",routingKey,message);
    return "succ";
}

• 4、此時如果我們把消費者的監聽去掉之後再傳送訊息，在管理後臺就可以看到 5 秒之後訊息會被刪除，10 秒之後佇列會被刪除。

PS：如果同時給佇列和單條訊息都設定了 TTL，則會以時間短的為主。

其他屬性

佇列中還有其他一些屬性可以設定，在這裡我們就不一一舉例了：

• x-message-ttl：佇列中訊息的存活時間（毫秒），達到TTL的訊息可能會被刪除。
• x-expires：佇列在多長時間（毫秒）沒有被訪問以後會被刪除。
• x-max-length：佇列中的最大訊息數。
• x-max-length-bytes：佇列的最大容量（bytes）。
• overflow：佇列溢位之後的策略。主要可以配置如下引數：reject-publish - 直接丟棄最近釋出的訊息，如若啟用了 publisher confirm（釋出者確認），釋出者將通過傳送 basic.nack 訊息通知拒絕，如果當前佇列繫結有多個消費者，則訊息在收到 basic.nack 拒絕通知後，仍然會被髮布到其他佇列；drop-head - 丟棄佇列頭部訊息（叢集模式下只支援這種策略） reject-publish-dlx - 最近釋出的訊息會進入死信佇列。
• x-dead-letter-exchange：佇列的死信交換機。
• x-dead-letter-routing-key：死信交換機的路由鍵。
• x-single-active-consumer：true/false。表示是否最多隻允許一個消費者消費，如果有多個消費者同時繫結，則只會啟用第一個，除非第一個消費者被取消或者死亡，才會自動轉到下一個消費者。
• x-max-priority：佇列中訊息的最大優先順序， 訊息的優先順序不能超過它。
• x-queue-mode：3.6.0 版本引入的，主要是為了實現惰性載入。佇列將收到的訊息儘可能快的進行持久化操作到磁碟上，然後只有在使用者請求的時候才會載入到 RAM 記憶體。這個引數支援兩個值：default 和 lazy。當不進行設定的時候，就是預設為 default，不做任何改變；當設定為 lazy 就會進行懶載入。
• x-queue-master-locator：為了保證訊息的 FIFO，所以在高可用叢集模式下需要選擇一個節點作為主節點。這個引數主要有三種模式：min-masters- 託管最小數量的繫結主機的節點；client-local- 選擇宣告的佇列已經連線到客戶端的節點；random- 隨機選擇一個節點。

神奇的死信佇列（Dead Letter）

上面的引數介紹中，提到了死信佇列，這又是什麼新鮮的東西呢？其實從名字上來看很好理解，就是指的已死的訊息，或者說無家可歸的訊息。一個訊息進入死信佇列，主要有以下三種條件：

• 1、訊息被消費者拒絕並且未設定重回佇列。

• 2、訊息過期（即設定了 TTL）。

• 3、佇列達到最大長度，超過了 Max length 或 Max length bytes，則佇列頭部的訊息會被髮送到死信佇列。

死信佇列實戰

• 1、在上面定義的 RabbitConfig 類中，定義一個死信交換機，並將之前的 ttl 佇列新增一個屬性 x-dead-letter-exchange，最後再將死信佇列和死信交換機進行繫結：

//直連死信交換機(也可以用topic或者fanout型別交換機)
@Bean("deatLetterExchange")
public DirectExchange deatLetterExchange(){
    return new DirectExchange("LONGLY_WOLF_DEAD_LETTER_DIRECT_EXCHANGE");
}
@Bean("ttlQueue")
public Queue ttlQueue(){
    Map<String, Object> map = new HashMap<String, Object>();
    map.put("x-message-ttl", 5000);//佇列中所有訊息5秒後過期
    map.put("x-dead-letter-exchange", "LONGLY_WOLF_DEAD_LETTER_DIRECT_EXCHANGE");//已死訊息會進入死信交換機
    return new Queue("LONGLY_WOLF_TTL_QUEUE",false,false,false,map);
}
//死信佇列
@Bean("deadLetterQueue")
public Queue deadLetterQueue(){
    return new Queue("LONGLY_WOLF_DEAD_LETTER_QUEUE");
}

• 2、在 ExchangeConsumer 消費者類上將監聽 TTL 佇列的監聽取消，註釋掉監聽：

	/**
     * 監聽ttl訊息佇列
     */
    @RabbitHandler
//    @RabbitListener(queues = "LONGLY_WOLF_TTL_QUEUE")
    public void ttlConsumer(Message message){
        System.out.println("ttl佇列收到訊息：" + new String(message.getBody()));
        System.out.println("ttl佇列收到訊息：" + JSONObject.toJSONString(message.getMessageProperties()));
    }

• 3、此時 TTL 佇列無消費者，並且設定了訊息的 TTL 為 5 秒，所以 5 秒之後就會進入死信佇列。
• 5、訪問介面：http://localhost:8080/exchange/send/ttl?routingKey=test&msg=測試死信佇列，傳送訊息之後，等待 5 秒就檢視訊息，進入死信佇列：

訊息真的傳送成功了嗎

瞭解了訊息的基本傳送功能之後，就可以高枕無憂了嗎？訊息發出去之後，消費者真的收到訊息了嗎？訊息傳送之後如何知道訊息傳送成功了？假如傳送訊息路由錯了導致無法路由到佇列怎麼辦？大家是不是都有這些疑問呢？彆著急，接下來就讓我們來一一來分析一下。

一條訊息從生產者開始傳送訊息到消費者消費完訊息主要可以分為以下 4 個階段：

• 1、生產者將訊息傳送到 Broker （即：RabbitMQ 的交換機）。
• 2、交換機將訊息路由到佇列。
• 3、佇列收到訊息後儲存訊息。
• 4、消費者從佇列獲取訊息進行消費。

接下來我們就從這 4 個步驟上來逐步分析 RabbitMQ 如何保證訊息傳送的可靠性。

訊息真的到達交換機了嗎

當我們傳送一條訊息之後，如何知道對方收到訊息了？這就和我們寫信一樣，寫一封信出去，如何知道對方收到我們寄出去的信？最簡單的方式就是對方也給我們回一封信，我們收到對方的回信之後就可以知道自己的信已經成功寄達。

在 RabbitMQ 中服務端也提供了 2 種方式來告訴客戶端（生產者）是否收到訊息：Transaction（事務）模式和 Confirm（確認）模式。

Transaction（事務） 模式

在 Java API 程式設計中開啟事務只需要增加以下程式碼即可：

 try {
     channel.txSelect();//開啟事務
     channel.basicPublish("", QUEUE_NAME, null, msg.getBytes());
     channel.txCommit();//提交事務
 }catch (Exception e){
     channel.txRollback();//訊息回滾
 }

在 Spring Boot 中需要對 RabbitTemplate 進行事務設定：

@Bean
public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory){
    RabbitTemplate rabbitTemplate = new RabbitTemplate();
    rabbitTemplate.setConnectionFactory(connectionFactory);
    rabbitTemplate.setChannelTransacted(true);//開啟事務
    return rabbitTemplate;
}

為了瞭解 RabbitMQ 當中事務機制的原理，我們在 Wireshark 中輸入 ip.addr==192.168.1.1 對本地 ip 進行抓包，傳送一條訊息之後，抓到如下資料包：

通過資料包，可以得出開啟事務之後，除了原本的傳送訊息之外，多出了開啟事務和事務提交的通訊：

開啟事務之後，有一個致命的缺點就是傳送訊息流程會被阻塞。也就是說必須一條訊息傳送成功之後，才會允許傳送另一條訊息。正因為事務模式有這個缺點，所以一般情況下並不建議在生產環境開啟事務，那麼有沒有更好的方式來實現訊息的送達確認呢？那麼就讓我們再看看Confirm（確認）模式。

Confirm（確認）模式

訊息確認模式又可以分為三種（事務模式和確認模式無法同時開啟）：

• 單條確認模式：傳送一條訊息，確認一條訊息。此種確認模式的效率也不高。
• 批量確認模式：傳送一批訊息，然後同時確認。批量傳送有一個缺點就是同一批訊息一旦有一條訊息傳送失敗，就會收到失敗的通知，需要將這一批訊息全部重發。
• 非同步確認模式：一邊傳送一邊確認，訊息可能被單條確認也可能會被批量確認。

Java API 實現確認模式

• 單條訊息確認模式

channel.confirmSelect();//開啟確認模式
channel.basicPublish("",QUEUE_NAME,null,msg.getBytes());
if (channel.waitForConfirms()){//wait.ForConfirms(long time)方法可以指定等待時間
    System.out.println("訊息確認傳送成功");
}

• 批量確認模式

channel.confirmSelect();//開啟確認模式
//批量傳送
for (int i=0;i<10;i++){
    channel.basicPublish("",QUEUE_NAME,null,msg.getBytes());
}
try{
    channel.waitForConfirmsOrDie();
}catch (IOException e){//只要有1條訊息未被確認，就會丟擲異常
    System.out.println("有訊息傳送失敗了");
}

• 非同步確認模式

channel.addConfirmListener(new ConfirmListener() {
    /**
      * 已確認訊息，即傳送成功後回撥
      * @param deliveryTag -唯一標識id（即傳送訊息時獲取到的nextPublishSeqNo）
      * @param multiple - 是否批量確認，當multiple=true，表示<=deliveryTag的訊息被批量確認，multiple=false，表示只確認了單條
      */
    @Override
    public void handleAck(long deliveryTag, boolean multiple) throws IOException {//成功回撥
        System.out.println("收到確認訊息了");
        //TODO 可以做一些想做的事
    }

    /**
       * 傳送失敗訊息後回撥
       * @param deliveryTag -唯一標識id（即傳送訊息時獲取到的nextPublishSeqNo）
       * @param multiple - 是否批量確認，當multiple=true，表示<=deliveryTag的訊息被批量確認，multiple=false，表示只確認了單條
       */
    @Override
    public void handleNack(long deliveryTag, boolean multiple) throws IOException {//失敗回撥
        if (multiple) {//批量確認，<deliveryTag的訊息都傳送失敗
            //TODO 訊息重發？
        } else {//非批量，=deliveryTag的訊息傳送失敗
            //TODO 訊息重發？
        }
    }
});

channel.confirmSelect();//開啟確認模式
for (int i=0;i<10;i++){//批量傳送
    long nextSeqNo = channel.getNextPublishSeqNo();//獲取傳送訊息的唯一標識(從1開始遞增)
    //TODO 可以考慮把訊息id存起來
    channel.basicPublish("",QUEUE_NAME,null,msg.getBytes());
}

SpringBoot 實現確認模式

通過配置檔案 spring.rabbitmq.publisher-confirm-type 引數進行配置確認（舊版本是 spring.rabbitmq.publisher-confirms 引數）。

• 1、新增配置檔案屬性配置

spring:
  rabbitmq:
    publisher-confirm-type: correlated # none-表示禁用回撥(預設) simple- 參考RabbitExchangeController#sendWithSimpleConfirm()方法

• 2、RabbitConfig 配置檔案中修改如下：

 @Bean
    public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory){
        RabbitTemplate rabbitTemplate = new RabbitTemplate();
        rabbitTemplate.setConnectionFactory(connectionFactory);
//        rabbitTemplate.setChannelTransacted(true);//開啟事務
        //訊息是否成功傳送到Exchange
        rabbitTemplate.setConfirmCallback(new RabbitTemplate.ConfirmCallback() {
            @Override
            public void confirm(CorrelationData correlationData, boolean ack, String cause) {
                if (!ack){//訊息傳送失敗
                    System.out.println("訊息傳送失敗，原因為：" + cause);
                    return;
                }
                //訊息傳送成功
                System.out.println("訊息傳送成功");
            }
        });
        return rabbitTemplate;
    }

這樣當我們傳送訊息成功之後，就會收到回撥。

• 3、當上面的引數配置修改為 simple，則需要在傳送訊息的時候使用 invoke 呼叫 waitForConfirms 或者 waitForConfirmsOrDie 方法來確認是否傳送成功：

 @GetMapping(value="/send/confirm")
 public String sendWithSimpleConfirm(String routingKey,@RequestParam(value = "msg",defaultValue = "no direct message") String msg){
       //使用waitForConfirms方法確認
        boolean sendFlag = rabbitTemplate.invoke(operations -> {
            rabbitTemplate.convertAndSend(
                    "LONGLY_WOLF_DIRECT_EXCHANGE",
                    "routingKey",
                    msg
            );
            return rabbitTemplate.waitForConfirms(5000);
        });
        //也可以使用waitForConfirmsOrDie方法確認
        boolean sendFlag2 = rabbitTemplate.invoke(operations -> {
            rabbitTemplate.convertAndSend(
                    "LONGLY_WOLF_DIRECT_EXCHANGE",
                    "routingKey",
                    msg
            );
            try {
                rabbitTemplate.waitForConfirmsOrDie(5000);
            }catch (Exception e){
                return false;
            }
            return true;
        });
        System.out.println(sendFlag);
        System.out.println(sendFlag2);
        return "succ";
    }

訊息無法從交換機路由到正確的佇列怎麼辦

上面通過事務或者確認機制確保了訊息成功傳送到交換機，那麼接下來交換機會負責將訊息路由到佇列，這時候假如佇列不存在或者路由錯誤就會導致訊息路由失敗，這又該如何保證呢？

同樣的，RabbitMQ 中也提供了 2 種方式來確保訊息可以正確路由到佇列：開啟監聽模式或者通過新增備份交換機模式來備份資料。

監聽回撥

上面介紹的是訊息是否傳送到交換機的回撥，而從交換機路由到佇列，同樣可以開啟確認模式。

Java API 方式開啟監聽模式

下面就是開啟監聽主要程式碼，為了節省篇幅，省略了其餘不相干程式碼（完成程式碼已上傳至 GitHub）

channel.addReturnListener(new ReturnListener() {
     @Override
     public void handleReturn(int replyCode, String replyText, String exchange, String routingKey, AMQP.BasicProperties properties, byte[] body) throws IOException {
         System.out.println("收到未路由到佇列的回撥訊息：" + new String(body));
     }
 });
//注意這裡的第三個引數，mandatory需要設定為true（傳送一個錯誤的路由，即可收到回撥）
channel.basicPublish(EXCHANGE_NAME,"ERROR_ROUTING_KEY",true,null,msg.getBytes());

Spring Boot 開啟監聽模式

在 RabitConfig 類中新增如下配置：

 @Bean
public RabbitTemplate rabbitTemplate(ConnectionFactory connectionFactory){
    RabbitTemplate rabbitTemplate = new RabbitTemplate();
    rabbitTemplate.setConnectionFactory(connectionFactory);

    rabbitTemplate.setMandatory(true);//開啟監聽回撥
    //訊息是否成功被路由到佇列，沒有路由到佇列時會收到回撥（原setReturnCallback在2.0版本已過期）
    rabbitTemplate.setReturnsCallback(new RabbitTemplate.ReturnsCallback() {
        @Override
        public void returnedMessage(ReturnedMessage returnedMessage) {
            System.out.println("收到未路由到佇列的回撥訊息：" + new String(returnedMessage.getMessage().getBody()));
        }
    });
    return rabbitTemplate;
}

備份交換機

除了開啟監聽的方式，還可以通過定義備份交換機的方式來實現，當原交換機無法正確路由到佇列時，則會進入備份交換機，再由備份交換機路由到正確佇列（要注意區分備份交換機和死信交換機的區別）。

Java API 實現備份交換機

下面就是一個實現備份交換機的例子，因為這裡備份交換機定義的是 Topic 型別，所有路由必須滿足定義好的路由，實際使用中一般會設定會 Fanout，因為無法預測錯誤的路由到底是多少：

 //宣告交換機且指定備份交換機
Map<String,Object> argMap = new HashMap<String,Object>();
argMap.put("alternate-exchange","TEST_ALTERNATE_EXCHANGE");
channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT,false,false,argMap);
//佇列和交換機進行繫結
channel.queueBind(QUEUE_NAME,EXCHANGE_NAME,ROUTEING_KEY);

//宣告備份交換機和備份佇列，並繫結（為了防止收不到訊息，備份交換機一般建議設定為Fanout型別）
channel.queueDeclare("BAK_QUEUE", false, false, false, null);
channel.exchangeDeclare("TEST_ALTERNATE_EXCHANGE", BuiltinExchangeType.TOPIC);
channel.queueBind("BAK_QUEUE","TEST_ALTERNATE_EXCHANGE","ERROR.#");

String msg = "I'm a bak exchange msg";
channel.basicPublish(EXCHANGE_NAME,"ERROR.ROUTING_KEY",null,msg.getBytes());

Spring Boot 實現備份交換機

Spring Boot 實現備份交換機原理和 Java API 實現相同：

• 1、首先在 RabbiConfig 中新增兩個交換機，一個是原始交換機，一個是備份交換機，同時新增一個備份佇列和備份交換機進行繫結，這裡的備份交換機是一個 Fanout 型別，注意因為這裡主要是演示備份交換機，所以這裡的原始交換機沒有和任何佇列繫結，也就無法路由到佇列，從而使得訊息進入備份交換機：

//用於測試備份交換機的原直連交換機
@Bean("bakDirectEchange")
public DirectExchange bakDirectEchange(){
    Map argMap = new HashMap<>();
    argMap.put("alternate-exchange", "LONGLY_WOLF_BAK_FANOUT_EXCHANGE");
    return new DirectExchange("LONGLY_WOLF_BAK_ORIGIN_DIRECT_EXCHANGE",false,false,argMap);
}

//備份廣播交換機
@Bean("bakFanoutExchange")
public FanoutExchange bakFanoutExchange(){
    return new FanoutExchange("LONGLY_WOLF_BAK_FANOUT_EXCHANGE");
}
//備份佇列
@Bean("bakQueue")
public Queue bakQueue(){
    return new Queue("LONELY_WOLF_BAK_QUEUE");
}
//備份交換機和備份佇列進行繫結
@Bean
public Binding BindExchange(@Qualifier("bakQueue") Queue queue, @Qualifier("bakFanoutExchange") FanoutExchange fanoutExchange){
    return BindingBuilder.bind(queue).to(fanoutExchange);
}

2、在消費者類 ExchangeConsumer 中監聽備份佇列：

 /**
  * 監聽備份訊息佇列
  */
@RabbitHandler
@RabbitListener(queues = "LONELY_WOLF_BAK_QUEUE")
public void bakQueueConsumer(Message message){
    System.out.println("備份佇列收到訊息：" + new String(message.getBody()));
}

• 3、最後在生產者類 RabbitExchangeController 中新增一個訊息傳送的方法進行訊息傳送：

@GetMapping(value="/send/bak")
public String sendBak(String routingKey,@RequestParam(value = "msg",defaultValue = "no bak message") String msg){
    rabbitTemplate.convertAndSend("LONGLY_WOLF_BAK_ORIGIN_DIRECT_EXCHANGE",routingKey,msg);
    return "succ";
}

呼叫之後可以看到，備份佇列會收到訊息，從而說明了訊息在無法路由到佇列時會進入到備份佇列。

佇列儲存訊息後發生異常怎麼辦

在保證了前面兩個階段的可靠性之後，訊息終於安全抵達了佇列，那麼這時候就絕對安全了嗎？

當我們的消費者的消費速度跟不上生產者的生產速度時，就會導致訊息堆積在佇列中，而預設訊息是沒有持久化的，存在於記憶體之中，所以假如伺服器當機等故障發生，就會導致佇列中的資料丟失。

這裡的解決方案也很簡單，就是將訊息進行持久化，在 RabbitMQ 當中，持久化也可以分為 3 種：交換機持久化，佇列持久化和訊息持久化。

雖然說持久化能一定程度上保證訊息的可靠性，然而當出現了伺服器的磁碟損壞，依然可能出現訊息丟失，所以為了更加完美，RabbitMQ 叢集可能是必須的，當然，本文不會涉及到叢集的知識，叢集的知識以及搭建會放到下次再來分析。

交換機持久化

宣告交換機時，durable 引數設定為 true。

佇列持久化

宣告佇列時，durable 引數設定為 true。

訊息持久化

傳送訊息時可以將訊息設定為持久化。

Java API 訊息持久化

在 Java API 中，可以通過如下方式設定訊息持久化：

//deliveryMode=2表示訊息持久化
AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder().deliveryMode(2).build();
channel.basicPublish("exchangeName","routingKey",properties,msg.getBytes());

Spring Boot 訊息持久化

在 Spring Boot 中可以通過如下方式將訊息設定為持久化：

MessageProperties messageProperties = new MessageProperties();
messageProperties.setDeliveryMode(MessageDeliveryMode.PERSISTENT);//訊息持久化
Message message = new Message(msg.getBytes(), messageProperties);
rabbitTemplate.convertAndSend("exchangeName","routingKey",message);

消費者消費訊息失敗了怎麼辦

踏遍千山萬水，經過 3 層地獄模式，訊息終於被消費者拿到手了，然而悲劇的事情又發生了，消費者消費訊息的時候可能因為消費者本身的問題或者其他意外導致了消費者消費訊息失敗了，這時候訊息還是沒能被正確處理，這時候難道眼睜睜看著最後關頭了束手無策了嗎？

非也，作為一款如此優秀的訊息佇列，怎麼可能沒考慮到這種場景呢。還記不記得上面我們提到的確認模式，實際上，上面的兩種確認模式都屬於服務端的確認，在 RabbitMQ 中為消費者也提供了確認模式，這就是消費者的確認。

消費者確認（ack）

佇列當中會把訊息刪除的前提就是這條訊息被消費者消費掉了，但是伺服器如何知道訊息被消費了呢？這就是需要通過消費者確認之後才會刪除，而我們前面在介紹訊息傳送的時候貌似並沒有看到消費者確認流程，這是因為消費者預設在收到訊息後會給伺服器一個應答，服務端收到消費者的應答之後，就會刪除訊息。

Java API 實現消費者應答

在 Java API 中應答方式有兩種，自動應答和手動應答，當自動應答時，則只要消費者收到訊息就會給服務端確認，不在乎訊息是否消費成功。

• 1、新建一個消費者 AckConsumer 類（省略了包名和匯入），這裡為了實現方便，通過生產者的頭部標記來決定採用何種應答策略：

public class AckConsumer {
    private static String QUEUE_NAME = "ACK_QUEUE";
    public static void main(String[] args) throws Exception{
        //1.宣告連線
        ConnectionFactory factory = new ConnectionFactory();
        factory.setUri("amqp://username:password@ip:port");

        //2.建立連線
        Connection conn = factory.newConnection();
        //3.建立訊息通道
        Channel channel = conn.createChannel();
        //4.宣告佇列（預設交換機AMQP default，Direct）
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        System.out.println(" 等待接收訊息...");

        // 建立消費者
        Consumer consumer = new DefaultConsumer(channel) {
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, AMQP.BasicProperties properties,
                                       byte[] body) throws IOException {
                System.out.println("收到訊息: " + new String(body, "UTF-8"));
                Map<String,Object> map = properties.getHeaders();//獲取頭部訊息
                String ackType = map.get("ackType").toString();
                if (ackType.equals("ack")){//手動應答
                    channel.basicAck(envelope.getDeliveryTag(),true);
                }else if(ackType.equals("reject-single")){//拒絕單條訊息
                    //拒絕訊息。requeue參數列示訊息是否重新入隊
                    channel.basicReject(envelope.getDeliveryTag(),false);
                    //                    channel.basicNack(envelope.getDeliveryTag(),false,false);
                }else if (ackType.equals("reject-multiple")){//拒絕多條訊息
                    //拒絕訊息。multiple參數列示是否批量拒絕，為true則表示<deliveryTag的訊息都被拒絕
                    channel.basicNack(envelope.getDeliveryTag(),true,false);
                }
            }
        };

        //開始獲取訊息,第二個引數 autoAck表示是否開啟自動應答
        channel.basicConsume(QUEUE_NAME, false, consumer);
    }
}

• 2、新建一個生產者 AckProducer 類（省略了包名和匯入）：

public class AckProducter {
    private static String QUEUE_NAME = "ACK_QUEUE";//佇列
    private static String EXCHANGE_NAME = "ACK_EXCHANGE";//交換機
    private static String ROUTEING_KEY = "test";
    public static void main(String[] args) throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setUri("amqp://admin:123456@47.107.155.197:5672");
        // 建立連線
        Connection conn = factory.newConnection();
        // 建立訊息通道
        Channel channel = conn.createChannel();
        Map<String, Object> headers = new HashMap<String, Object>(1);
        headers.put("ackType", "ack");//請應答
//        headers.put("ackType", "reject-single");//請單條拒絕
//        headers.put("ackType", "reject-multiple");//請多條拒絕

        AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
                .contentEncoding("UTF-8")  // 編碼
                .headers(headers) // 自定義屬性
                .messageId(String.valueOf(UUID.randomUUID()))
                .build();

        String msg = "I'm a ack message";
        //宣告佇列
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        //宣告交換機
        channel.exchangeDeclare(EXCHANGE_NAME, BuiltinExchangeType.DIRECT,false);
        //佇列和交換機進行繫結
        channel.queueBind(QUEUE_NAME,EXCHANGE_NAME,ROUTEING_KEY);
        // 傳送訊息
        channel.basicPublish(EXCHANGE_NAME, ROUTEING_KEY, properties, msg.getBytes());

        channel.close();
        conn.close();
    }
}

Spring Boot 實現消費者應答

在 Spring Boot 中消費者給服務端的確認方式分為 3 種：

• NONE：自動應答（ack）。

• MANUAL：手動應答（ack）。如果設定為手動應答，而消費者又遲遲不給伺服器應答，那麼訊息就會一直存在佇列，可能會造成訊息堆積和重複消費現象。

• AUTO：當沒有丟擲異常時會自動應答（ack）。除此外，當發生異常時，分為以下三種情況：

  • 1、當丟擲 AmqpRejectAndDontRequeueException 異常時，訊息會被拒絕，也不會重新入隊。
  • 2、當丟擲 ImmediateAcknowledgeAmqpException 異常時，消費者會自動傳送應答給服務端。
  • 3、當丟擲其他異常時，訊息會被拒絕，且會重新入隊。當出現這種情況且消費者只有一個時，非常容易造成死迴圈，所以應該極力避免這種情況的發生。

• 1、Spring Boot 中可以通過引數控制應答型別：

spring:
  rabbitmq:
    listener:
      type: simple # direct型別是2.0之後才有的
      simple:
        acknowledge-mode: manual

• 2、在消費者類 ExchangeConsumer 中新建一個方法來監聽佇列，其中第一個註釋掉的方法是原本存在的，第二個方法是新增的，主要新增了幾個引數，注意 Channel 是 com.rabbitmq.client.Channel 包下的：

/**
 * 監聽繫結了direct交換機的的訊息佇列
 */
//    @RabbitHandler
//    @RabbitListener(queues = "LONGLY_WOLF_ORDER_QUEUE")
//    public void directConsumer(String msg){
//        System.out.println("direct交換機收到訊息：" + msg);
//    }

/**
 * 監聽繫結了direct交換機的的訊息佇列，並進行手動應答
 */
@RabbitHandler
@RabbitListener(queues = "LONGLY_WOLF_ORDER_QUEUE")
public void manualDirectConsumer(String msg, Channel channel,Message message) throws IOException {
    System.out.println("direct交換機收到訊息：" + msg + "。此訊息需要手動應答");
    channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);//手動應答
}

• 3、或者也可以通過 SimpleMessageListenerContainer 類實現監聽，新建一個 RabbitAckConfig 類（省略了包名和匯入）：

@Configuration
public class RabbitAckConfig {
    @Bean
    public SimpleMessageListenerContainer messageListenerContainer(ConnectionFactory connectionFactory){
        SimpleMessageListenerContainer container = new SimpleMessageListenerContainer();
        container.setConnectionFactory(connectionFactory);
        container.setQueueNames("LONGLY_WOLF_ORDER_QUEUE");//設定監聽佇列名
        container.setAcknowledgeMode(AcknowledgeMode.MANUAL);//手動確認
        container.setMessageListener((ChannelAwareMessageListener) (message, channel) -> {//訊息處理
            System.out.println("收到訊息：" + new String(message.getBody()) + "。此訊息需要手動應答");
            channel.basicAck(message.getMessageProperties().getDeliveryTag(),false);
        });
        return container;
    }
}

PS：需要注意的是，這兩種方式不要同時使用，否則無法保證訊息會被哪個監聽到。

僅靠 RabbitMQ 自身可靠效能實現業務需求嗎

上面介紹的兩種確認模式，服務端確認和消費者確認。其中服務端確認是會回撥給生產者的，所以生產者可以知道訊息是否已經到達伺服器且是否正確路由到佇列，然而，對於消費者的確認，生產者是不知道的，這是因為訊息佇列的作用之一就是為了實現生產者和消費者的解耦，換言之，消費者知道訊息成功傳送到佇列，但是無法知道訊息是否被消費者消費。

所以為了知道訊息是否被成功消費，主要有兩種思路：

• 1、消費者在消費成功之後需要回撥生產者提供的API來告知訊息已經被消費
• 2、服務端在收到消費者確認後給生產者一個回執通知

然而假如生產者遲遲沒有收到消費者是否消費成功的資訊，那麼可能就需要補償，比如微信支付等都會有補償機制，間隔一定時間就將訊息重發一次。

補償機制同時也會帶來一個問題，假如說消費者消費成功了，但是在告訴生產者的時候失敗了，那麼這時候訊息如果再次補償就會造成重複消費，所以消費者需要支援冪等（即無論一條訊息被消費多少次，都不會改變結果）。當然，同時還有其他場景需要考慮，比如訊息之間的依賴性等等問題都需要結合具體業務場景來具體處理。

總結

本文主要講述了 RabbitMQ 的訊息傳送方式，介紹了 3 種不同交換機的方式，同時最後也從傳送訊息的主要 4 個步驟分析了每一個步驟如何保證訊息的可靠性，並分別通過 Java API 和 Spring Boot 提供了示例，中間還提到了死信佇列，死信佇列本質也是一個佇列，只不過儲存的訊息比較特殊，相信通過本文，大家對 RabbitMQ 會有一個更深層次的瞭解。