RabbitMQ實戰：性能和安全

本系列是「RabbitMQ實戰：高效部署分佈式消息隊列」書籍的總結筆記。

前兩篇介紹了RabbitMQ在可用性、監控方面的考慮，這是基礎保障，由於在某些場景下是不允許丟失消息的，但它和性能每每是對立的，須要根據業務場景作取捨。

當處理一些敏感數據時，好比銀行卡信息，須要考慮安全性問題，上一篇總結了數據傳輸安全方面的知識點，這裏就比較好理解了。

經過介紹，你會了解到：

• 對速度的考慮
• 對內存和進程的考慮
• 對安全的考慮

對速度的考慮

有不少因素影響RabbitMQ投遞消息的速度，包括消息持久化、路由算法、綁定數目、以及消息確認策略等，下面分別來介紹。

消息持久化

當發佈消息時，須要決定丟失其中的任何消息是否能夠接受，若是能夠接受，能夠將delivery-model設置爲1，消息就不會持久化到硬盤了。

消息確認

當消費消息時，能夠在隊列訂閱時，經過設定no-ack標記加快消息投遞，若是設置爲true，服務器就會在消息發送給客戶端後自動將其出隊。

這樣，處理完消息以後就無須再發送確認消息回服務器了，能極大地加快消費者消費消息，但因爲某些緣由鏈接中斷了，或客戶端應用程序發生故障了，消息就永遠消息了。

路由算法和綁定規則

前面介紹了3種類型的交換器：direct、fanout、topic，每種交換器表明了服務器實現的特定路由算法，會根據消息的路由鍵以及隊列與交換器之間的綁定來選擇隊列。

在服務器端，交換器和綁定做爲記錄條目存儲在Mnesia數據庫中，當匹配消息路由鍵時，會嘗試查找對應路由鍵的綁定。

fanout交換器在路由消息的時候，會忽略路由鍵，不須要進行查找。direct只有一個綁定，也會比較快，topic存儲的路由信息比較複雜，因爲路由鍵能夠包含以點分隔的多個詞，因此匹配消息路由鍵不只僅是簡單字符串的匹配，也會佔用更多內存。

RabbitMQ實現了trie樹數據結構用來存儲綁定路由鍵模式，以支持快速查詢，關於這種數據結構，我以前沒接觸過，聽說比桶狀哈希表還快，後面專門寫一篇介紹這個數據結構吧。

投遞消息

在交換器找到消息須要路由的目的地以後，會將目的地列表返回給rabbit_router，以後會將消息的副本投遞到每個目的地，若是發佈的消息中mandatory和immediate標記設置爲false，這個過程會以異步方式執行，從客戶端角度看，服務器會變得很快，不然會同步投遞。

當mandatory標誌位設置爲true時，若是exchange根據自身類型和消息routeKey沒法找到一個符合條件的queue，那麼會調用basic.return方法將消息返還給生產者，當mandatory設爲false時，出現上述情形broker會直接將消息扔掉。

當immediate標誌位設置爲true時，若是exchange在將消息route到queue(s)時發現對應的queue上沒有消費者，那麼這條消息不會放入隊列中。當與消息routeKey關聯的全部queue(一個或多個)都沒有消費者時，該消息會經過basic.return方法返還給生產者。

假如找到了投遞的隊列且有消費者準備好接收消息，若是隊列爲空，消息會直接發送給消費者，不會通過隊列這一步，會極大提高速度，因此制定容量規劃並計算消息的進出率時，應儘量讓隊列保持爲空，若是消費滯後致使隊列填滿的化，服務器會收到內存告警，並將消息刷出磁盤。

還有個參數要注意：auto-ack，消費者接收到消息後，會馬上確認消息，而不用等到邏輯處理好。

以上說的提升速度的方法大部分都會犧牲可用性，要根據不一樣的業務場景進行平衡。

對內存和進程的考慮

在設計應用程序的時候，會有兩個基本限制：選擇的技術容許作什麼，以及當前硬件設定容許作什麼。上面討論了第一點：不一樣消息路由和分發算法如何影響設計決策。關於第二點，須要考慮AMQP的元素須要多少內存，以及Erlang VM對能夠建立的進程總數的硬件限制。

內存考慮

關於內存佔用，書上有詳細說明，這裏只列出分析結果，供你們在預估容量時參考：(√表示哪些表會爲隊列聲明添加記錄)

1.隊列元數據

2.交換器元數據

3.綁定元數據

一個持久化隊列綁定到一個瞬時交換器會致使在rabbit_semi_durable_router表上建立條目。

Erlang進程計數

能夠在節點啓動時指定Erlang節點上能運行的最大Erlang進程數，默認設置是每一個Erlang節點1048576，即2^20個。

Erlang應用程序在整個生命週期中會屢次建立並銷燬進程。好比，RabbitMQ接收到AMQP客戶端的TCP鏈接時，會建立一個進程進行管理該鏈接，同時，會有不少Erlang進程來處理消息存儲的邏輯。

主要經過如下事件來增長進程數：到服務器的新鏈接、建立新的信道以及隊列聲明。一條新的鏈接會建立四個新的進程，一個新的通道也會建立四個新的進程，隊列的開銷最小，每一個隊列一個進程。

對安全的考慮

有些消息，想以一種安全的方式進行傳輸，可使用SSL協議在消息通訊終端傳輸數據，RabbitMQ默認支持SSL，只須要配置相應的證書，使用openssl庫進行設置和操做。

關於證書、openssl以及ssl，上一篇文章詳細介紹了，如今來看看如何使用。

服務端

只須要修改下rabbitmq的配置便可，在rabbitmq.config中添加ssl_listeners和ssl_options配置項：

[
    {rabbit,[
        {ssl_listeners, [5671]},
        {ssl_options, [
            {cacertfile,"/path/to/rmqca/cacert.pem"},
            {certfile,"/path/to/server/cert.pem"},
            {keyfile,"/path/to/server/key.pem"},
            {verify,verify},
            {fail_if_no_peer_cert,false}
        ]}
    ]}

]
複製代碼

配置中指定了ca的證書，服務端的證書，以及服務端的祕鑰。

客戶端

require_once(__DIR__ . '/../amqp.inc');

define('HOST', 'localhost');
define('PORT', 5671);
define('USER', 'guest');
define('PASS', 'guest');
define('VHOST', '/');
define('AMQP_DEBUG', true);
define('CERTS_PATH',
  '/path/to/ca/folder/');
  
$ssl_options = array(
      'cafile' => CERTS_PATH . '/rmqca/cacert.pem',
      'local_cert' => CERTS_PATH . '/phpcert.pem',
      'verify_peer' => true
  );
$conn = new AMQPSSLConnection(HOST, PORT, USER, PASS, VHOST, $ssl_options);

function shutdown($conn){
    $conn->close();
}
register_shutdown_function('shutdown', $conn);

while(1){}
複製代碼

客戶端代碼指定了ca根證書和客戶端證書和祕鑰，phpcert.pem是客戶端證書、祕鑰、ca根證書的合併文件。

$ cat client/key.pem > phpcert.pem
$ cat client/cert.pem >> phpcert.pem
$ cat rmqca/cacert.pem >> phpcert.pem
複製代碼

下一篇會介紹下RabbitMQ的插件，以便自定義插件擴展RabbitMQ功能。

歡迎掃描下方二維碼，關注個人我的微信公衆號，查看更多文章 ~