詳解RabbitMQ

原創 东风麦芽糖 2020-07-05 07:51

0.學習內容

  • 瞭解常見的MQ產品
  • 瞭解RabbitMQ的5種消息模型
  • 會使用Spring AMQP

1.RabbitMQ

1.1.搜索類服務的問題

如果項目裏使用了redis或者ES等索引庫，我們在後臺修改了關係型數據庫(mysql、oracle等數據庫)的數據，但是redis裏與ES裏都是舊數據，這顯然不對。該如何解決？

這裏有兩種解決方案：

  • 方案1：每當後臺對關係型數據庫做增刪改操作，同時要修改索引庫數據及靜態頁面
  • 方案2：搜索服務ES和前端頁面服務對外提供操作接口，後臺在增刪改後，調用接口

以上兩種方式都有同一個嚴重問題：就是代碼耦合，後臺服務中需要嵌入搜索和商品頁面服務，違背了微服務的獨立原則。

所以，我們會通過另外一種方式來解決這個問題：消息隊列

1.2.消息隊列（MQ）

1.2.1.什麼是消息隊列

消息隊列，即MQ，Message Queue。

在這裏插入圖片描述
消息隊列是典型的：生產者、消費者模型。生產者不斷向消息隊列中生產消息，消費者不斷的從隊列中獲取消息。因爲消息的生產和消費都是異步的，而且只關心消息的發送和接收，沒有業務邏輯的侵入，這樣就實現了生產者和消費者的解耦。

結合前面所說的問題：

  • 對數據庫增刪改以後，無需去操作索引庫或靜態頁面，只是發送一條消息，也不關心消息被誰接收。
  • 搜索服務和靜態頁面服務接收消息，分別去處理索引庫和靜態頁面。

如果以後有其它系統也依賴改數據庫的服務的數據，同樣監聽消息即可，改數據庫服務無需任何代碼修改。

1.2.2.AMQP和JMS

MQ是消息通信的模型，並不是具體實現。現在實現MQ的有兩種主流方式：AMQP、JMS。
在這裏插入圖片描述

在這裏插入圖片描述

兩者間的區別和聯繫：

  • JMS是定義了統一的接口，來對消息操作進行統一；AMQP是通過規定協議來統一數據交互的格式
  • JMS限定了必須使用Java語言；AMQP只是協議，不規定實現方式，因此是跨語言的。
  • JMS規定了兩種消息模型；而AMQP的消息模型更加豐富

1.2.3.常見MQ產品

  • ActiveMQ：基於JMS
  • RabbitMQ：基於AMQP協議，erlang語言開發，穩定性好
  • RocketMQ：基於JMS，阿里巴巴產品，目前交由Apache基金會
  • Kafka：分佈式消息系統，高吞吐量

1.2.4.RabbitMQ

RabbitMQ是基於AMQP的一款消息管理系統

官網： http://www.rabbitmq.com/

官方教程：http://www.rabbitmq.com/getstarted.html

在這裏插入圖片描述
在這裏插入圖片描述

1.3.下載和安裝

1.3.1.下載

官網下載地址：http://www.rabbitmq.com/download.html

在這裏插入圖片描述

目前最新版本是：3.7.5

我們這裏使用的是：3.4.1版本

1.3.2.安裝

docker安裝robbitmq

Centos下安裝RabbitMQ

2.五種消息模型

RabbitMQ提供了6種消息模型，但是第6種其實是RPC，並不是MQ，因此不予學習。那麼也就剩下5種。

但是其實3、4、5這三種都屬於訂閱模型，只不過進行路由的方式不同。

在這裏插入圖片描述
我們通過一個demo工程來了解下RabbitMQ的工作方式：

依賴：

	<dependencies>
		<dependency>
			<groupId>org.apache.commons</groupId>
			<artifactId>commons-lang3</artifactId>
			<version>3.3.2</version>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-amqp</artifactId>
		</dependency>
		<dependency>
			<groupId>org.springframework.boot</groupId>
			<artifactId>spring-boot-starter-test</artifactId>
		</dependency>
	</dependencies>

我們抽取一個建立RabbitMQ連接的工具類，方便其他程序獲取連接：

public class ConnectionUtil {
    /**
     * 建立與RabbitMQ的連接
     * @return
     * @throws Exception
     */
    public static Connection getConnection() throws Exception {
        //定義連接工廠
        ConnectionFactory factory = new ConnectionFactory();
        //設置服務地址
        factory.setHost("192.168.56.101");
        //端口
        factory.setPort(5672);
        //設置賬號信息，用戶名、密碼、vhost
        factory.setVirtualHost("/sgw");
        factory.setUsername("sgw");
        factory.setPassword("sgw");
        // 通過工程獲取連接
        Connection connection = factory.newConnection();
        return connection;
    }
}

2.1.基本消息模型

官方介紹：

在這裏插入圖片描述

RabbitMQ是一個消息代理：它接受和轉發消息。 你可以把它想象成一個郵局：當你把郵件放在郵箱裏時，你可以確定郵差先生最終會把郵件發送給你的收件人。 在這個比喻中，RabbitMQ是郵政信箱，郵局和郵遞員。

RabbitMQ與郵局的主要區別是它不處理紙張，而是接受，存儲和轉發數據消息的二進制數據塊。

在這裏插入圖片描述

P（producer/ publisher）：生產者，一個發送消息的用戶應用程序。

C（consumer）：消費者，消費和接收有類似的意思，消費者是一個主要用來等待接收消息的用戶應用程序

隊列（紅色區域）：rabbitmq內部類似於郵箱的一個概念。雖然消息流經rabbitmq和你的應用程序，但是它們只能存儲在隊列中。隊列只受主機的內存和磁盤限制，實質上是一個大的消息緩衝區。許多生產者可以發送消息到一個隊列，許多消費者可以嘗試從一個隊列接收數據。

總之：

生產者將消息發送到隊列，消費者從隊列中獲取消息，隊列是存儲消息的緩衝區。

我們將用Java編寫兩個程序;發送單個消息的生產者，以及接收消息並將其打印出來的消費者。我們將詳細介紹Java API中的一些細節，這是一個消息傳遞的“Hello World”。

我們將調用我們的消息發佈者（發送者）Send和我們的消息消費者（接收者）Recv。發佈者將連接到RabbitMQ，發送一條消息，然後退出。

2.1.1.生產者發送消息

public class Send {
    //隊列名稱
    private final static String QUEUE_NAME = "simple_queue";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接以及mq通道
        Connection connection = ConnectionUtil.getConnection();
        // 從連接中創建通道，這是完成大部分API的地方。
        Channel channel = connection.createChannel();

        // 聲明（創建）隊列，必須聲明隊列才能夠發送消息，我們可以把消息發送到隊列中。
        // 聲明一個隊列是冪等的 - 只有當它不存在時纔會被創建
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);

        // 消息內容
        String message = "Hello World!";
        channel.basicPublish("", QUEUE_NAME, null, message.getBytes());
        System.out.println(" [x] Sent '" + message + "'");

        //關閉通道和連接
        channel.close();
        connection.close();
    }
}

控制檯：

在這裏插入圖片描述

2.1.2.管理工具中查看消息

進入隊列頁面，可以看到新建了一個隊列：simple_queue

在這裏插入圖片描述

點擊隊列名稱，進入詳情頁，可以查看消息：

在這裏插入圖片描述

在控制檯查看消息並不會將消息消費，所以消息還在。

2.1.3.消費者獲取消息

public class Recv {
    private final static String QUEUE_NAME = "simple_queue";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 創建通道
        Channel channel = connection.createChannel();
        // 聲明隊列
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        // 定義隊列的消費者
        DefaultConsumer consumer = new DefaultConsumer(channel) {
            // 獲取消息，並且處理，這個方法類似事件監聽，如果有消息的時候，會被自動調用
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, BasicProperties properties,
                    byte[] body) throws IOException {
                // body 即消息體
                String msg = new String(body);
                System.out.println(" [x] received : " + msg + "!");
            }
        };
        // 監聽隊列，第二個參數：是否自動進行消息確認（一般設置爲false，後邊會講）。
        channel.basicConsume(QUEUE_NAME, true, consumer);
    }
}

控制檯：

在這裏插入圖片描述

這個時候，隊列中的消息就沒了：

在這裏插入圖片描述

我們發現，消費者已經獲取了消息，但是程序沒有停止，一直在監聽隊列中是否有新的消息。一旦有新的消息進入隊列，就會立即打印.

2.1.4.消息確認機制（ACK）

通過剛纔的案例可以看出，消息一旦被消費者接收，隊列中的消息就會被刪除。

那麼問題來了：RabbitMQ怎麼知道消息被接收了呢？

如果消費者領取消息後，還沒執行操作就掛掉了呢？或者拋出了異常？消息消費失敗，但是RabbitMQ無從得知，這樣消息就丟失了！

因此，RabbitMQ有一個ACK機制。當消費者獲取消息後，會向RabbitMQ發送回執ACK，告知消息已經被接收。不過這種回執ACK分兩種情況：

  • 自動ACK：消息一旦被接收，消費者自動發送ACK
  • 手動ACK：消息接收後，不會發送ACK，需要手動調用

大家覺得哪種更好呢？

這需要看消息的重要性：

  • 如果消息不太重要，丟失也沒有影響，那麼自動ACK會比較方便
  • 如果消息非常重要，不容丟失。那麼最好在消費完成後手動ACK，否則接收消息後就自動ACK，RabbitMQ就會把消息從隊列中刪除。如果此時消費者宕機，那麼消息就丟失了。

我們之前的測試都是自動ACK的，如果要手動ACK，需要改動我們的代碼：

public class Recv2 {
    private final static String QUEUE_NAME = "simple_queue";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 創建通道
        final Channel channel = connection.createChannel();
        // 聲明隊列
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        // 定義隊列的消費者
        DefaultConsumer consumer = new DefaultConsumer(channel) {
            // 獲取消息，並且處理，這個方法類似事件監聽，如果有消息的時候，會被自動調用
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, BasicProperties properties,
                    byte[] body) throws IOException {
                // body 即消息體
                String msg = new String(body);
                System.out.println(" [x] received : " + msg + "!");
                // 手動進行ACK
                channel.basicAck(envelope.getDeliveryTag(), false);
            }
        };
        // 監聽隊列，第二個參數false，手動進行ACK
        channel.basicConsume(QUEUE_NAME, false, consumer);
    }
}

注意到最後一行代碼：

channel.basicConsume(QUEUE_NAME, false, consumer);

如果第二個參數爲true，則會自動進行ACK；如果爲false，則需要手動ACK。方法的聲明：
在這裏插入圖片描述

2.1.4.1.自動ACK存在的問題

修改消費者，添加異常，如下：

在這裏插入圖片描述

生產者不做任何修改，直接運行，消息發送成功：

在這裏插入圖片描述

運行消費者，程序拋出異常。但是消息依然被消費：
在這裏插入圖片描述

管理界面：

在這裏插入圖片描述

2.1.4.2.演示手動ACK

修改消費者，把自動改成手動（去掉之前製造的異常）

在這裏插入圖片描述
生產者不變，再次運行：

在這裏插入圖片描述

運行消費者

在這裏插入圖片描述

但是，查看管理界面，發現：

在這裏插入圖片描述

停掉消費者的程序，發現：

在這裏插入圖片描述

這是因爲雖然我們設置了手動ACK，但是代碼中並沒有進行消息確認！所以消息並未被真正消費掉。

當我們關掉這個消費者，消息的狀態再次稱爲Ready

修改代碼手動ACK：

在這裏插入圖片描述
執行：

在這裏插入圖片描述
消息消費成功！
（如何避免消息丟失，面試題：使用手動ACK，不用自動ACK；但這不是最終解決方案）

2.2.work消息模型

工作隊列或者競爭消費者模式

在這裏插入圖片描述

在第一篇教程中，我們編寫了一個程序，從一個命名隊列中發送並接受消息。在這裏，我們將創建一個工作隊列，在多個工作者之間分配耗時任務。

工作隊列，又稱任務隊列。主要思想就是避免執行資源密集型任務時，必須等待它執行完成。相反我們稍後完成任務，我們將任務封裝爲消息並將其發送到隊列。 在後臺運行的工作進程將獲取任務並最終執行作業。當你運行許多作業時，任務將在他們之間共享，但是一個消息只能被一個消費者獲取。

這個概念在Web應用程序中特別有用，因爲在短的HTTP請求窗口中無法處理複雜的任務。

接下來我們來模擬這個流程：

​ P：生產者：任務的發佈者

​ C1：消費者，領取任務並且完成任務，假設完成速度較快

​ C2：消費者2：領取任務並完成任務，假設完成速度慢

面試題：如何避免消息堆積？

1） 採用workqueue，多個消費者監聽同一隊列。

2）接收到消息以後，通過線程池，異步消費。

2.2.1.生產者

生產者與案例1中的幾乎一樣：

public class Send {
    private final static String QUEUE_NAME = "test_work_queue";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 獲取通道
        Channel channel = connection.createChannel();
        // 聲明隊列
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        // 循環發佈任務
        for (int i = 0; i < 50; i++) {
            // 消息內容
            String message = "task .. " + i;
            channel.basicPublish("", QUEUE_NAME, null, message.getBytes());
            System.out.println(" [x] Sent '" + message + "'");

            Thread.sleep(i * 2);
        }
        // 關閉通道和連接
        channel.close();
        connection.close();
    }
}

不過這裏我們是循環發送50條消息。

2.2.2.消費者1

在這裏插入圖片描述

2.2.3.消費者2

在這裏插入圖片描述

與消費者1基本類似，就是沒有設置消費耗時時間。

這裏是模擬有些消費者快，有些比較慢。

接下來，兩個消費者一同啓動，然後發送50條消息：

在這裏插入圖片描述

可以發現，兩個消費者各自消費了25條消息，而且各不相同，這就實現了任務的分發。

2.2.4.能者多勞

剛纔的實現有問題嗎？

  • 消費者1比消費者2的效率要低，一次任務的耗時較長
  • 然而兩人最終消費的消息數量是一樣的
  • 消費者2大量時間處於空閒狀態，消費者1一直忙碌

現在的狀態屬於是把任務平均分配，正確的做法應該是消費越快的人，消費的越多。

怎麼實現呢？

我們可以使用basicQos方法和prefetchCount = 1設置。 這告訴RabbitMQ一次不要向工作人員發送多於一條消息。 或者換句話說，不要向工作人員發送新消息，直到它處理並確認了前一個消息。 相反，它會將其分派給不是仍然忙碌的下一個工作人員。

在這裏插入圖片描述

再次測試：

在這裏插入圖片描述

2.3.訂閱模型分類

在之前的模式中，我們創建了一個工作隊列。 工作隊列背後的假設是：每個任務只被傳遞給一個工作人員。 在這一部分，我們將做一些完全不同的事情 - 我們將會傳遞一個信息給多個消費者。 這種模式被稱爲“發佈/訂閱”。

訂閱模型示意圖：
在這裏插入圖片描述

解讀：

1、1個生產者，多個消費者

2、每一個消費者都有自己的一個隊列

3、生產者沒有將消息直接發送到隊列，而是發送到了交換機

4、每個隊列都要綁定到交換機

5、生產者發送的消息，經過交換機到達隊列，實現一個消息被多個消費者獲取的目的

X（Exchanges）：交換機一方面：接收生產者發送的消息。另一方面：知道如何處理消息，例如遞交給某個特別隊列、遞交給所有隊列、或是將消息丟棄。到底如何操作，取決於Exchange的類型。

Exchange類型有以下幾種：

  • Fanout：廣播，將消息交給所有綁定到交換機的隊列

  • Direct：定向，把消息交給符合指定routing key 的隊列

  • Topic：通配符，把消息交給符合routing pattern（路由模式） 的隊列

Exchange（交換機）只負責轉發消息，不具備存儲消息的能力，因此如果沒有任何隊列與Exchange綁定，或者沒有符合路由規則的隊列，那麼消息會丟失！

2.4.訂閱模型-Fanout

Fanout，也稱爲廣播。

流程圖：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-3UqcovVG-1576574337872)(assets/1527086564505.png)]

在廣播模式下，消息發送流程是這樣的：

  • 1） 可以有多個消費者
  • 2） 每個消費者有自己的queue（隊列）
  • 3） 每個隊列都要綁定到Exchange（交換機）
  • 4） 生產者發送的消息，只能發送到交換機，交換機來決定要發給哪個隊列，生產者無法決定。
  • 5） 交換機把消息發送給綁定過的所有隊列
  • 6） 隊列的消費者都能拿到消息。實現一條消息被多個消費者消費

2.4.1.生產者

兩個變化：

  • 1） 聲明Exchange，不再聲明Queue
  • 2） 發送消息到Exchange，不再發送到Queue
public class Send {

    private final static String EXCHANGE_NAME = "fanout_exchange_test";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 獲取通道
        Channel channel = connection.createChannel();
        
        // 聲明exchange，指定類型爲fanout
        channel.exchangeDeclare(EXCHANGE_NAME, "fanout");
        
        // 消息內容
        String message = "Hello everyone";
        // 發佈消息到Exchange
        channel.basicPublish(EXCHANGE_NAME, "", null, message.getBytes());
        System.out.println(" [生產者] Sent '" + message + "'");

        channel.close();
        connection.close();
    }
}

2.4.2.消費者1

public class Recv {
    private final static String QUEUE_NAME = "fanout_exchange_queue_1";

    private final static String EXCHANGE_NAME = "fanout_exchange_test";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 獲取通道
        Channel channel = connection.createChannel();
        // 聲明隊列
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);

        // 綁定隊列到交換機
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "");

        // 定義隊列的消費者
        DefaultConsumer consumer = new DefaultConsumer(channel) {
            // 獲取消息，並且處理，這個方法類似事件監聽，如果有消息的時候，會被自動調用
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, BasicProperties properties,
                    byte[] body) throws IOException {
                // body 即消息體
                String msg = new String(body);
                System.out.println(" [消費者1] received : " + msg + "!");
            }
        };
        // 監聽隊列，自動返回完成
        channel.basicConsume(QUEUE_NAME, true, consumer);
    }
}

要注意代碼中：隊列需要和交換機綁定

2.4.3.消費者2

public class Recv2 {
    private final static String QUEUE_NAME = "fanout_exchange_queue_2";

    private final static String EXCHANGE_NAME = "fanout_exchange_test";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 獲取通道
        Channel channel = connection.createChannel();
        // 聲明隊列
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);

        // 綁定隊列到交換機
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "");
        
        // 定義隊列的消費者
        DefaultConsumer consumer = new DefaultConsumer(channel) {
            // 獲取消息，並且處理，這個方法類似事件監聽，如果有消息的時候，會被自動調用
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, BasicProperties properties,
                    byte[] body) throws IOException {
                // body 即消息體
                String msg = new String(body);
                System.out.println(" [消費者2] received : " + msg + "!");
            }
        };
        // 監聽隊列，手動返回完成
        channel.basicConsume(QUEUE_NAME, true, consumer);
    }
}

2.4.4.測試

我們運行兩個消費者，然後發送1條消息：
在這裏插入圖片描述

在這裏插入圖片描述

2.5.訂閱模型-Direct

有選擇性的接收消息

在訂閱模式中，生產者發佈消息，所有消費者都可以獲取所有消息。

在路由模式中，我們將添加一個功能 - 我們將只能訂閱一部分消息。 例如，我們只能將重要的錯誤消息引導到日誌文件（以節省磁盤空間），同時仍然能夠在控制檯上打印所有日誌消息。

但是，在某些場景下，我們希望不同的消息被不同的隊列消費。這時就要用到Direct類型的Exchange。

在Direct模型下，隊列與交換機的綁定，不能是任意綁定了，而是要指定一個RoutingKey（路由key）

消息的發送方在向Exchange發送消息時，也必須指定消息的routing key。

在這裏插入圖片描述

P：生產者，向Exchange發送消息，發送消息時，會指定一個routing key。

X：Exchange（交換機），接收生產者的消息，然後把消息遞交給 與routing key完全匹配的隊列

C1：消費者，其所在隊列指定了需要routing key 爲 error 的消息

C2：消費者，其所在隊列指定了需要routing key 爲 info、error、warning 的消息

2.5.1.生產者

此處我們模擬商品的增刪改，發送消息的RoutingKey分別是：insert、update、delete

public class Send {
    private final static String EXCHANGE_NAME = "direct_exchange_test";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 獲取通道
        Channel channel = connection.createChannel();
        // 聲明exchange，指定類型爲direct
        channel.exchangeDeclare(EXCHANGE_NAME, "direct");
        // 消息內容
        String message = "商品新增了， id = 1001";
        // 發送消息，並且指定routing key 爲：insert ,代表新增商品
        channel.basicPublish(EXCHANGE_NAME, "insert", null, message.getBytes());
        System.out.println(" [商品服務：] Sent '" + message + "'");

        channel.close();
        connection.close();
    }
}

2.5.2.消費者1

我們此處假設消費者1只接收兩種類型的消息：更新商品和刪除商品。

public class Recv {
    private final static String QUEUE_NAME = "direct_exchange_queue_1";
    private final static String EXCHANGE_NAME = "direct_exchange_test";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 獲取通道
        Channel channel = connection.createChannel();
        // 聲明隊列
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        
        // 綁定隊列到交換機，同時指定需要訂閱的routing key。假設此處需要update和delete消息
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "update");
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "delete");

        // 定義隊列的消費者
        DefaultConsumer consumer = new DefaultConsumer(channel) {
            // 獲取消息，並且處理，這個方法類似事件監聽，如果有消息的時候，會被自動調用
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, BasicProperties properties,
                    byte[] body) throws IOException {
                // body 即消息體
                String msg = new String(body);
                System.out.println(" [消費者1] received : " + msg + "!");
            }
        };
        // 監聽隊列，自動ACK
        channel.basicConsume(QUEUE_NAME, true, consumer);
    }
}

2.5.3.消費者2

我們此處假設消費者2接收所有類型的消息：新增商品，更新商品和刪除商品。

public class Recv2 {
    private final static String QUEUE_NAME = "direct_exchange_queue_2";
    private final static String EXCHANGE_NAME = "direct_exchange_test";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 獲取通道
        Channel channel = connection.createChannel();
        // 聲明隊列
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        
        // 綁定隊列到交換機，同時指定需要訂閱的routing key。訂閱 insert、update、delete
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "insert");
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "update");
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "delete");

        // 定義隊列的消費者
        DefaultConsumer consumer = new DefaultConsumer(channel) {
            // 獲取消息，並且處理，這個方法類似事件監聽，如果有消息的時候，會被自動調用
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, BasicProperties properties,
                    byte[] body) throws IOException {
                // body 即消息體
                String msg = new String(body);
                System.out.println(" [消費者2] received : " + msg + "!");
            }
        };
        // 監聽隊列，自動ACK
        channel.basicConsume(QUEUE_NAME, true, consumer);
    }
}

2.5.4.測試

我們分別發送增、刪、改的RoutingKey，發現結果：

在這裏插入圖片描述

2.6.訂閱模型-Topic

Topic類型的Exchange與Direct相比，都是可以根據RoutingKey把消息路由到不同的隊列。只不過Topic類型Exchange可以讓隊列在綁定Routing key 的時候使用通配符！

Routingkey 一般都是有一個或多個單詞組成，多個單詞之間以”.”分割，例如： item.insert

通配符規則：

​ #：匹配一個或多個詞

​ *：匹配不多不少恰好1個詞

舉例：

​ audit.#：能夠匹配audit.irs.corporate 或者 audit.irs

​ audit.*：只能匹配audit.irs

在這裏插入圖片描述

在這個例子中，我們將發送所有描述動物的消息。消息將使用由三個字（兩個點）組成的routing key發送。路由關鍵字中的第一個單詞將描述速度，第二個顏色和第三個種類：“..”。

我們創建了三個綁定：Q1綁定了綁定鍵“* .orange.”，Q2綁定了“.*.rabbit”和“lazy.＃”。

Q1匹配所有的橙色動物。

Q2匹配關於兔子以及懶惰動物的消息。

練習，生產者發送如下消息，會進入那個隊列：

quick.orange.rabbit à Q1 Q2

lazy.orange.elephant à Q1 Q2

quick.orange.fox à Q1

lazy.pink.rabbit à Q2

quick.brown.fox à 不匹配任意隊列，被丟棄

quick.orange.male.rabbit à

orange à

2.6.1.生產者

使用topic類型的Exchange，發送消息的routing key有3種： item.isnert、item.update、item.delete：

public class Send {
    private final static String EXCHANGE_NAME = "topic_exchange_test";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 獲取通道
        Channel channel = connection.createChannel();
        // 聲明exchange，指定類型爲topic
        channel.exchangeDeclare(EXCHANGE_NAME, "topic");
        // 消息內容
        String message = "新增商品 : id = 1001";
        // 發送消息，並且指定routing key 爲：insert ,代表新增商品
        channel.basicPublish(EXCHANGE_NAME, "item.insert", null, message.getBytes());
        System.out.println(" [商品服務：] Sent '" + message + "'");

        channel.close();
        connection.close();
    }
}

2.6.2.消費者1

我們此處假設消費者1只接收兩種類型的消息：更新商品和刪除商品

public class Recv {
    private final static String QUEUE_NAME = "topic_exchange_queue_1";
    private final static String EXCHANGE_NAME = "topic_exchange_test";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 獲取通道
        Channel channel = connection.createChannel();
        // 聲明隊列
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        
        // 綁定隊列到交換機，同時指定需要訂閱的routing key。需要 update、delete
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "item.update");
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "item.delete");

        // 定義隊列的消費者
        DefaultConsumer consumer = new DefaultConsumer(channel) {
            // 獲取消息，並且處理，這個方法類似事件監聽，如果有消息的時候，會被自動調用
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, BasicProperties properties,
                    byte[] body) throws IOException {
                // body 即消息體
                String msg = new String(body);
                System.out.println(" [消費者1] received : " + msg + "!");
            }
        };
        // 監聽隊列，自動ACK
        channel.basicConsume(QUEUE_NAME, true, consumer);
    }
}

2.6.3.消費者2

我們此處假設消費者2接收所有類型的消息：新增商品，更新商品和刪除商品。

/**
 * 消費者2
 */
public class Recv2 {
    private final static String QUEUE_NAME = "topic_exchange_queue_2";
    private final static String EXCHANGE_NAME = "topic_exchange_test";

    public static void main(String[] argv) throws Exception {
        // 獲取到連接
        Connection connection = ConnectionUtil.getConnection();
        // 獲取通道
        Channel channel = connection.createChannel();
        // 聲明隊列
        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        
        // 綁定隊列到交換機，同時指定需要訂閱的routing key。訂閱 insert、update、delete
        channel.queueBind(QUEUE_NAME, EXCHANGE_NAME, "item.*");

        // 定義隊列的消費者
        DefaultConsumer consumer = new DefaultConsumer(channel) {
            // 獲取消息，並且處理，這個方法類似事件監聽，如果有消息的時候，會被自動調用
            @Override
            public void handleDelivery(String consumerTag, Envelope envelope, BasicProperties properties,
                    byte[] body) throws IOException {
                // body 即消息體
                String msg = new String(body);
                System.out.println(" [消費者2] received : " + msg + "!");
            }
        };
        // 監聽隊列，自動ACK
        channel.basicConsume(QUEUE_NAME, true, consumer);
    }
}

2.7.持久化

如何避免消息丟失？

1） 消費者的ACK機制。可以防止消費者丟失消息。

2） 但是，如果在消費者消費之前，MQ就宕機了，消息就沒了。

如何可以將消息進行持久化呢？

要將消息持久化，前提是：隊列、Exchange都持久化

2.7.1.交換機持久化

在這裏插入圖片描述

2.7.2.隊列持久化

在這裏插入圖片描述

2.7.3.消息持久化

在這裏插入圖片描述

3.Spring AMQP

3.1.簡介

Sprin有很多不同的項目，其中就有對AMQP的支持：

在這裏插入圖片描述

Spring AMQP的頁面：http://spring.io/projects/spring-amqp
在這裏插入圖片描述

注意這裏一段描述：

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-lOt9ANmy-1576574337881)(assets/1532767227821.png)]

​ Spring-amqp是對AMQP協議的抽象實現，而spring-rabbit 是對協議的具體實現，也是目前的唯一實現。底層使用的就是RabbitMQ。

2.2.依賴和配置

添加AMQP的啓動器：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-amqp</artifactId>
</dependency>

在application.yml中添加RabbitMQ地址：

spring:
  rabbitmq:
    host: 192.168.56.101
    username: sgw
    password: sgw
    virtual-host: /sgw

2.3.監聽者

在SpringAmqp中，對消息的消費者進行了封裝和抽象，一個普通的JavaBean中的普通方法，只要通過簡單的註解，就可以成爲一個消費者。

@Component
public class Listener {

    @RabbitListener(bindings = @QueueBinding(
            value = @Queue(value = "spring.test.queue", durable = "true"),
            exchange = @Exchange(
                    value = "spring.test.exchange",
                    ignoreDeclarationExceptions = "true",
                    type = ExchangeTypes.TOPIC
            ),
            key = {"#.#"}))
    public void listen(String msg){
        System.out.println("接收到消息：" + msg);
    }
}
  • @Componet：類上的註解，註冊到Spring容器
  • @RabbitListener：方法上的註解，聲明這個方法是一個消費者方法，需要指定下面的屬性：
    • bindings：指定綁定關係，可以有多個。值是@QueueBinding的數組。@QueueBinding包含下面屬性：
      • value：這個消費者關聯的隊列。值是@Queue，代表一個隊列
      • exchange：隊列所綁定的交換機，值是@Exchange類型
      • key：隊列和交換機綁定的RoutingKey

類似listen這樣的方法在一個類中可以寫多個，就代表多個消費者。

2.4.AmqpTemplate

Spring最擅長的事情就是封裝，把他人的框架進行封裝和整合。

Spring爲AMQP提供了統一的消息處理模板：AmqpTemplate，非常方便的發送消息，其發送方法：

在這裏插入圖片描述

紅框圈起來的是比較常用的3個方法，分別是：

  • 指定交換機、RoutingKey和消息體
  • 指定消息
  • 指定RoutingKey和消息，會向默認的交換機發送消息

2.5.測試代碼

@RunWith(SpringRunner.class)
@SpringBootTest(classes = Application.class)
public class MqDemo {

    @Autowired
    private AmqpTemplate amqpTemplate;

    @Test
    public void testSend() throws InterruptedException {
        String msg = "hello, Spring boot amqp";
        this.amqpTemplate.convertAndSend("spring.test.exchange","a.b", msg);
        // 等待10秒後再結束
        Thread.sleep(10000);
    }
}

運行後查看日誌：
在這裏插入圖片描述
以上只是個人總結，下邊這篇文章是一位大牛總結的，大家可以參考學習：
RabbitMQ詳解

發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

低代碼與消息隊列的完美融合：打造高效開發與通信的組合

引言 消息隊列（Message Queue，MQ）是一種在分佈式系統中實現應用程序間通信的中間件技術。它的核心作用在於通過異步處理的方式，使得發送消息的應用程序（生產者）與接收消息的應用程序（消費者）解耦，從而提升系統的伸縮性、可靠性以及性

原創 2024-04-02 10:22:31

Apache RocketMQ 5.0 消息進階：如何支撐複雜的業務消息場景?

一致性 首先來看 RocketMQ 的第一個特性-事務消息，事務消息是 RocketMQ 與一致性相關的特性，也是 RocketMQ 有別於其他消息隊列的最具區分度的特性。 以大規模電商系統爲例，付款成功後會在交易系統中訂單數據庫將訂單

原創 2023-09-05 00:24:32

聯邦學習開源框架FATE架構

作者：京東科技 葛星宇 1.前言 本文除特殊說明外，所指的都是fate 1.9版本。 fate資料存在着多處版本功能與發佈的文檔不匹配的情況，各個模塊都有獨立的文檔，功能又有關聯，坑比較多，首先要理清楚各概念、模塊之間的關係。 2.網絡互聯

原創 2023-03-16 12:02:27

如何保證緩存和數據庫的一致性？

@[toc] 很多小夥伴在面試的時候，應該都遇到過類似的問題，如何確保緩存和數據庫的一致性？ 如果你對這個問題有過研究，應該可以發現這個問題其實很好回答，如果第一次聽到或者第一次遇到這個問題，估計會有點懵，今天我們來聊聊這個話題。 1. 問

原創 2022-04-30 14:16:08

Spring Cloud+Mybatis+Uniapp 構建分佈式微服務B2B2C O2O多商家入駐+直播+短視頻帶貨+多端支持商城

1. 平臺簡介 一個全新覆蓋全行業，以直播、短視頻帶貨，商家實體VR全景體驗，多營銷模式，分銷分傭，多商家入駐，多端支持的大型新零售電商平臺。 2. 平臺清單 系統管理平臺 + 商家端（PC+手機） + 消費端微服務 + 消費端（小程序

原創 2022-04-30 06:07:18

RabbitMQ 延遲消息應用場景及實現

RabbitMQ 延遲消息應用場景： 訂單指定時間內未支付則自動取消 用戶註冊後，三天內未登陸，自動短信提醒 新入駐店鋪，十天內未上傳產品，自動短信提醒 用戶發起退貨退款，3天內未得到處理則自動通知相關運營人員 預定會議，會議前10分鐘

原創 2021-12-25 21:39:27

rabbitmq-交換機類型和工作模式

1. 五種交換機類型 1.1 Direct exchange(直連交換機) 1.2 Topic exchange(主題交換機) 1.3 Fanout exchange(扇形交換機) 1.4 Headers exchange(頭交換機) 1.

原創 2021-12-25 21:36:27

服務啓動命令

mysql cd /usr/local/mysql/bin #啓動 service mysql start #重啓 service mysql restart #登錄 mysql -u 用戶名 -p docker # 啓動 system

原創 2021-12-25 21:36:26

4種延時任務實現方案

業務場景 我們買火車票或者叫外賣的時候，下完單之後會跳轉到支付頁面，頁面裏通常會有一個計時器，要求在指定時間內完成支付，否則訂單就會被自動取消。這就是延時任務的一個典型業務場景。分析這個場景，其實最關鍵的就是如何在訂單超時的時候立即觸發取

php開源社區 2021-12-25 21:35:53

goland設置go module

goland版本2019.3.2 go版本1.14  網上一大堆亂七八糟的什麼破文章，講了半天都沒講清這個go module怎麼實際運用，真滴煩躁，一giao我哩giaogiao！！！！！ 這邊我直接介紹下goland怎麼用go modul

osc_h8z06jiq 2021-12-25 21:28:42

架構設計之MQ選型

MQ的好處 在微服務架構中，消息隊列帶來哪些好處呢 1. 改善寫操作請求的響應時間：生產者寫給隊列即可返回，無需等待下游服務響應，縮短鏈路調用時間 2. 更容易進行伸縮：小功能解偶爲獨立服務，更容易伸縮，提升處理能力 3. 削峯填谷：控制消

原創 2021-12-25 21:28:11

必須要掌握的 RabbitMQ 操作命令

@[toc] 關於 RabbitMQ 的管理，我們可以通過網頁來進行，在松哥前面的文章中也和小夥伴們做了相關的介紹了： RabbitMQ 管理頁面該如何使用 除了通過 Web 管理頁面來進行管理之外，我們也可以通過命令行來進行管理，之前

原創 2021-12-25 21:26:42

常見消息中間件大 PK

@[toc] 說到消息中間件，估計大夥多多少少都能講出來一些，ActiveMQ、RabbitMQ、RocketMQ、Kafka 等等各種以及 JMS、AMQP 等各種協議，然而這些消息中間件各自都有什麼特點，我們在開發中又該選擇哪種呢？今天

原創 2021-12-25 21:26:42

RabbitMQ 中的 VirtualHost 該如何理解

當我們第一次安裝好一個 RabbitMQ 之後，我們可能都會通過 Web 頁面去管理這個 RabbitMQ，默認情況下，我們第一次使用的默認用戶是 guest。 登錄成功後，在 admin 選項卡可以查看所有用戶： 可以看到，每個用戶都有

原創 2021-12-25 21:26:41

RabbitMQ 管理頁面該如何使用

@[toc] RabbitMQ 的 web 管理頁面相信很多小夥伴都用過，隨便點一下估計也都知道啥意思，不過本着精益求精的思想，松哥還是想和大家捋一捋這個管理頁面的各個細節。 1. 概覽 首先，這個 Web 管理頁面大概就像下圖這樣： 首

原創 2021-12-25 21:26:41