RabbitMQ性能測試工具的使用

背景：最近看RabbitMQ相關知識，順便了解了一下他的性能測試工具。RabbitMQ Performance Testing Tools（PerfTest）是一款開源的性能測試工具。

工具：rabbitmq_server-3.7.8 + rabbitmq-perf-test-2.2.0 + Window7

1. RabbitMQ基本概念

RabbitMQ Broker：也叫broker server，它是一種傳輸服務。他的角色就是維護一條從Producer到Consumer的路線，保證數據能夠按照指定的方式進行傳輸。但是這個保證也不是100%的保證，但是對於普通的應用來說這已經足夠了。當然對於商業系統來說，可以再做一層數據一致性的guard，就可以徹底保證系統的一致性了。
Producer：消息生產者，即數據的發送方。消息生產者連接RabbitMQ服務器然後將消息投遞到Exchange。
Consumer：消息消費者，即數據的接收方。消息消費者訂閱隊列，RabbitMQ將Queue中的消息發送到消息消費者。
Exchange：生產者將消息發送到Exchange（交換器），由Exchange將消息路由到一個或多個Queue中（或者丟棄）。Exchange並不存儲消息。RabbitMQ中的Exchange有fanout、direct、topic、headers四種類型，每種類型對應不同的路由規則，後面詳細介紹這四種類型。
Queue：（隊列）是RabbitMQ的內部對象，用於存儲消息。消息消費者就是通過訂閱隊列來獲取消息的，RabbitMQ中的消息都只能存儲在Queue中，生產者生產消息並最終投遞到Queue中，消費者可以從Queue中獲取消息並消費。多個消費者可以訂閱同一個Queue，這時Queue中的消息會被平均分攤給多個消費者進行處理，而不是每個消費者都收到所有的消息並處理。
RoutingKey：生產者在將消息發送給Exchange的時候，一般會指定一個routing key，來指定這個消息的路由規則，而這個routing key需要與Exchange Type及binding key聯合使用才能最終生效。在Exchange Type與binding key固定的情況下（在正常使用時一般這些內容都是固定配置好的），我們的生產者就可以在發送消息給Exchange時，通過指定routing key來決定消息流向哪裏。RabbitMQ爲routing key設定的長度限制爲255 bytes。
Connection：（連接）。Producer和Consumer都是通過TCP連接到RabbitMQ Server的。以後我們可以看到，程序的起始處就是建立這個TCP連接。
Channels：（信道）。它建立在上述的TCP連接中。數據流動都是在Channel中進行的。也就是說，一般情況是程序起始建立TCP連接，第二步就是建立這個Channel。
Exchange Types：
fanout：fanout類型的Exchange路由規則非常簡單，它會把所有發送到該Exchange的消息路由到所有與它綁定的Queue中。生產者發送到Exchange的所有消息都會路由到綁定的Queue，並最終被兩個消費者消費。
direct：direct類型的Exchange路由規則也很簡單，它會把消息路由到那些binding key與routing key完全匹配的Queue中。（在實際使用RabbitMQ的過程中並沒有binding key這個參數，只有routing key，爲了區分我們把交換機和隊列綁定時傳的參數叫binding key，把發送消息時帶的這個參數叫routing key）
topic：前面講到direct類型的Exchange路由規則是完全匹配binding key與routing key，但這種嚴格的匹配方式在很多情況下不能滿足實際業務需求。topic類型的Exchange在匹配規則上進行了擴展，它與direct類型的Exchage相似，也是將消息路由到binding key與routing key相匹配的Queue中，但direct是完全匹配，而通過topic可以進行模糊匹配routing key爲一個句點號“. ”分隔的字符串（我們將被句點號“. ”分隔開的每一段獨立的字符串稱爲一個單詞），如“stock.usd.nyse”、“nyse.vmw”、“quick.orange.rabbit” binding key與routing key一樣也是句點號“. ”分隔的字符串 binding key中可以存在兩種特殊字符“”與“#”，用於做模糊匹配，其中“”用於匹配一個單詞，“#”用於匹配多個單詞（可以是零個）
headers：headers類型的Exchange不依賴於routing key與binding key的匹配規則來路由消息，而是根據發送的消息內容中的headers屬性進行匹配。在綁定Queue與Exchange時指定一組鍵值對；當消息發送到Exchange時，RabbitMQ會取到該消息的headers（也是一個鍵值對的形式），對比其中的鍵值對是否完全匹配Queue與Exchange綁定時指定的鍵值對；如果完全匹配則消息會路由到該Queue，否則不會路由到該Queue。

注：上述文字來自：https://blog.csdn.net/super_rd/article/details/70238869。感謝作者~~

2 .RabbitMQ性能測試工具

1）介紹

RabbitMQ有一個測試吞吐量的性能測試工具PerfTest。它是基於Java開發的客戶端。可以配置爲模擬基本和高級兩種負載。源碼下載地址：https://bintray.com/rabbitmq/java-tools/perf-test。

2）使用

a. PerfTest的安裝

將html目錄中的數據拷貝到bin目錄下：

將examples目錄中的文件也拷貝到bin目錄：

3）準備測試場景

這裏的測試場景爲：2個Producers將在30秒內向RabbitMQ發送消息。與此同時，1個Consumer將消費這些消息。

4）執行測試

在bin目錄下，執行如下命令，收集的數據會在public-consume-result.js中出現。

# runjava com.rabbitmq.perf.PerfTestMulti public-consume-spec.js public-consume-result.js

5）查看結果

a. 該工具使用HTML代碼展示執行結果。在bin目錄下新建文件：publish-consume-result.html，代碼如下：

b.開啓webserver。切換到bin的上一層目錄，執行如下命令：

# runjava com.rabbitmq.perf.WebServer. ./ 9099

這裏，./爲publish-consume-result.html所在目錄，9099爲監聽端口。

在瀏覽器中輸入：http://<RabbitMQ的IP>:9099/publish-consume-result.html。展示結果如下：

在項目的環境中，出現了這樣的場景：發送消息速率(send-msg-rate)波動較大，其波動幅度隨着時間增長逐漸縮小；接收消息的速率(recv-msg-rate)較爲平緩，消息的延遲(avg-latency)較大。發送消息速率波幅的逐漸減小是由於RabbitMQ自身的限流導致，消息的延遲較大是因爲有2個Producers在生產消息，而只有1個Consumer在消費，因此這裏可以考慮增加多一些的Consumer。

3. 常見問題

1）缺少“guest”賬號。

報錯：ACCESS_REFUSED。