本系列是「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功能。

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

RabbitMQ實戰：性能和安全