1. 程式人生 > >RabbitMQ實戰:性能和安全

RabbitMQ實戰:性能和安全

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功能。

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

技術分享圖片

RabbitMQ實戰:性能和安全