首頁 > 軟體

RabbitMQ之Queue屬性測試

2020-06-16 18:03:23

本篇圍繞 RabbitMQ 中最基本的 fabric – queue 進行討論,主要介紹其常用的幾個屬性設定,以及在實際使用中的約束條件。

常用queue屬性

rabbitmq-c程式碼中可以看到如下程式碼

上圖所示為
queue宣告時使用的結構體。其中最容易讓使用者迷惑的3個屬性是durableexclusiveauto_delete

上圖所示為
consumerqueue進行訊息消費時用於設定屬性的結構體。其中最容易讓使用者迷惑的屬性是exclusive(上圖中的exclusive註釋有點問題,請忽略)

測試過程

在編寫Python語言的測試程式時,我將行為分為以下幾步

  • 宣告7個具有不同屬性的queue,分別和名為test_exchage的exchange進行系結(因為exchange為fanout型別,所以測試程式碼中的routing_key其實是不起作用的);
  • 向exchange傳送具有persistent屬性的訊息(delivery_mode=2);
  • 建立7個消費者分別從上述7個queue中獲取訊息;

測試結果如下

可以看到,所有的7個消費者均收到了對應的訊息內容。 

下面我們從RabbitMQ伺服器測檢視以下上述測試能展現什麼資訊。

1.client和server建立了一條AMQP connection

2.在該connection上使用了channel1進程AMQP協定通訊。

3.連線建立時的使用者名稱為guest,以及各種channel屬性設定情況。

4.在當前channel上共存在7個消費者,分別從7個不同的queue上獲取訊息;該channel上的訊息均來自名為test_exchageexchange(請原諒我測試過程中的英文拼寫錯誤)。

Exchanges索引標籤上可以看到test_exchage下系結了哪些queue

Queues索引標籤上可以看到全部7queue的屬性情況

看到這裡,眼尖的同學可能會發現問題所在了,那就是用戶端程式碼中宣告的queue屬性並沒有全部生效,為什麼會這樣呢?

首先分別看一下程式碼中宣告的7queue在伺服器側的詳細資訊。

a.test_1_queue沒有設定任何屬性,在介面上沒有看到任何屬性。

b. test_2_queue設定了durable屬性,在介面上看到了“durable:true”。

 

c. test_3_queue設定了auto-delete屬性,在介面上看到了“auto-delete:true”。

d. test_4_queue同時設定了durableauto-delete屬性,在介面上看到了“durable:trueauto-delete:true”。

e. test_5_queue同時設定了durableexclusive屬性,但在介面上只看到了“Exlusive owner”的存在。

f. test_6_queue同時設定了auto_deleteexclusive屬性,在介面上同時看到“auto-delete:true”和“Exlusive owner”的存在。

g. test_7_queue同時設定了durableauto_deleteexclusive屬性,在介面上只看到了“auto-delete:true”和“Exlusive owner”的存在。

綜上,可以得出如下結論

  • durable屬性和auto-delete屬性可以同時生效
  • durable屬性和exclusive屬性會有性質上的衝突,兩者同時設定時,僅exclusive屬性生效
  • auto_delete屬性和exclusive屬性可以同時生效

除此之外,還能得到其它一些有趣的結論:

  • Queue的“Exlusive owner”對應的是connection而不是channel
  • Consumer存在於某個channel上的

 附上一張用戶端同時設定durableauto_deleteexclusive屬性的抓包截圖:

下面通過改變client側程式碼,模擬不同情況下各種屬性對queue的存在情況的影響。

a.在成功建立全部7queue後,通過Ctrl+C異常終止用戶端程式。

(上圖為全部建立時的狀態)

 

 停止後,queue的情況如下圖所示。

對比發現,此時只有 test_1_queue test_2_queue 仍舊存在,其它queue已經被RabbitMQ伺服器刪除掉了(思考原因)。

b.用戶端側執行到訊息傳送後,結束當前操作(無consumer情況)。程式碼調整如下

此時仍舊可以看到queue的宣告和系結都是成功的。

此時用戶端程式執行後會自動退出

再從web頁面檢視queue的情況如下

對比發現,此時僅test_1_queuetest_2_queuetest_3_queuetest_4_queue 存在(思考原因)。

      這裡有個細節值得說一下:雖然最終我們在web頁面上只看到了4queue的存在,但其實7queue都被成功建立過(抓包可以證明),如果你夠幸運,你也可能在web頁面上看到一閃而過的另外3queue。通過對比可以發現,導致另外3queue消失的原因是exclusive屬性的設定,前面我已經說過,queue的“Exlusive owner”對應的是connection,所以在這個實驗中可以確定的是,connection仍舊是存在的(這裡遺留個問題:為什麼python執行退出後連線仍舊存在),而此時實際上不存在的是consumer,所以需要對之前得到的結論進行加強:具有exclusive屬性的queue的存在條件是在connection上存在某個consumer訂閱了該queue同樣可以得到另外一個結論:可以在沒有建立consumer的情況下,建立出具有auto-delete屬性的queue

RabbitMQ官方文件中其實已經對上述現象進行了說明,只不過一語帶過,不注意的話容易忽略掉。在queue.declare方法中包含如下屬性說明

此時肯定有人會問,除了queue.declare中具有exclusive屬性,basic.consume中也具有exclusive屬性,後者是什麼含義呢?在文件說明中有如下內容

由此可以理解兩個屬性的差異和實際使用中應該注意的問題是什麼!(自行思考)

在此情況下,若執行RabbitMQ server的重新啟動(rabbitmqctl stop_app;rabbitmqctl start_app),可以看到僅有test_2_queuetest_4_queue仍舊存在。

測試版本

以上測試基於如下RabbitMQ版本

為什麼使用這個版本?(我猜肯定有人會問)因為這個實驗是我半年前就已經完成了的~~

CentOS 5.6 安裝RabbitMQ http://www.linuxidc.com/Linux/2013-02/79508.htm

RabbitMQ用戶端C++安裝詳細記錄 http://www.linuxidc.com/Linux/2012-02/53521.htm

用Python嘗試RabbitMQ http://www.linuxidc.com/Linux/2011-12/50653.htm

RabbitMQ叢集環境生產範例部署 http://www.linuxidc.com/Linux/2012-10/72720.htm

Ubuntu下PHP + RabbitMQ使用 http://www.linuxidc.com/Linux/2010-07/27309.htm

在CentOS上安裝RabbitMQ流程 http://www.linuxidc.com/Linux/2011-12/49610.htm

RabbitMQ概念及環境搭建 http://www.linuxidc.com/Linux/2014-12/110449.htm

RabbitMQ入門教學  http://www.linuxidc.com/Linux/2015-02/113983.htm


IT145.com E-mail:sddin#qq.com