本系列是「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功能。
歡迎掃描下方二維碼，關注我的個人微信公衆號，查看更多文章 ~
