本篇圍繞 RabbitMQ 中最基本的 fabric – queue 進行討論,主要介紹其常用的幾個屬性設置,以及在實際使用中的約束條件。
常用queue屬性
在 rabbitmq-c代碼中可以看到如下代碼
上圖所示為queue聲明時使用的結構體。其中最容易讓使用者迷惑的3個屬性是durable、exclusive和auto_delete。
上圖所示為consumer從queue進行消息消費時用於設置屬性的結構體。其中最容易讓使用者迷惑的屬性是exclusive(上圖中的exclusive注釋有點問題,請忽略)。
在編寫python語言的測試程序時,我將行為分為以下幾步
測試結果如下
可以看到,所有的7個消費者均收到了對應的消息內容。
下面我們從RabbitMQ服務器測查看以下上述測試能展現什麼信息。
1.client和server建立了一條AMQP connection。
2.在該connection上使用了channel號1進程AMQP協議通信。
3.連接建立時的用戶名為guest,以及各種channel屬性設置情況。
4.在當前channel上共存在7個消費者,分別從7個不同的queue上獲取消息;該channel上的消息均來自名為test_exchage的exchange(請原諒我測試過程中的英文拼寫錯誤)。
從Exchanges選項卡上可以看到test_exchage下綁定了哪些queue。
從Queues選項卡上可以看到全部7個queue的屬性情況
看到這裡,眼尖的同學可能會發現問題所在了,那就是客戶端代碼中聲明的queue屬性並沒有全部生效,為什麼會這樣呢?
首先分別看一下代碼中聲明的7個queue在服務器側的詳細信息。
a.test_1_queue沒有設置任何屬性,在界面上沒有看到任何屬性。
b. test_2_queue設置了durable屬性,在界面上看到了“durable:true”。
c. test_3_queue設置了auto-delete屬性,在界面上看到了“auto-delete:true”。
d. test_4_queue同時設置了durable和auto-delete屬性,在界面上看到了“durable:true和auto-delete:true”。
e. test_5_queue同時設置了durable和exclusive屬性,但在界面上只看到了“Exlusive owner”的存在。
f. test_6_queue同時設置了auto_delete和exclusive屬性,在界面上同時看到“auto-delete:true”和“Exlusive owner”的存在。
g. test_7_queue同時設置了durable、auto_delete和exclusive屬性,在界面上只看到了“auto-delete:true”和“Exlusive owner”的存在。
綜上,可以得出如下結論
除此之外,還能得到其它一些有趣的結論:
附上一張客戶端同時設置durable、auto_delete和exclusive屬性的抓包截圖:
下面通過改變client側代碼,模擬不同情況下各種屬性對queue的存在情況的影響。
a.在成功創建全部7個queue後,通過Ctrl+C異常終止客戶端程序。
(上圖為全部創建時的狀態)
停止後,queue的情況如下圖所示。
對比發現,此時只有 test_1_queue 和 test_2_queue 仍舊存在,其它queue已經被RabbitMQ服務器刪除掉了(思考原因)。
b.客戶端側執行到消息發送後,結束當前操作(無consumer情況)。代碼調整如下
此時仍舊可以看到queue的聲明和綁定都是成功的。
此時客戶端程序執行後會自動退出
再從web頁面查看queue的情況如下
對比發現,此時僅test_1_queue、test_2_queue、test_3_queue和test_4_queue 存在(思考原因)。
這裡有個細節值得說一下:雖然最終我們在web頁面上只看到了4個queue的存在,但其實7個queue都被成功創建過(抓包可以證明),如果你夠幸運,你也可能在web頁面上看到一閃而過的另外3個queue。通過對比可以發現,導致另外3個queue消失的原因是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_queue和test_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
RabbitMQ 的詳細介紹:請點這裡
RabbitMQ 的下載地址:請點這裡