rabbitmq部署的生產指南

像RabbitMQ這樣的數據服務通常有許多可調參數。一些配置對開發有很大的意義，但并不適合生產，本指南旨在為此提供幫助

虛擬主機

例如，在單租戶環境中，當您的RabbitMQ集群專門為生產中的單個系統供電時，使用默認的虛擬主機(/)是完全正確的

在多租戶環境中，為每個租戶/環境使用單獨的虛擬主機，例如project1_development， project1_production，project2_development和 project2_production等

用戶

對于生產環境，請刪除默認用戶(guest),默認用戶只能從本地主機默認連接，因為它具有眾所周知的憑據。不要啟用遠程連接，而應考慮使用具有管理權限和生成密碼的單獨用戶

建議每個應用程序使用一個單獨的用戶。例如，如果您有一個移動應用程序，一個Web應用程序和一個數據聚合系統，您將有3個獨立的用戶。這使得許多事情更容易：將客戶端連接與應用程序關聯

權限控制

認證和授權通常會混淆或互換使用。這是錯誤的，在RabbitMQ中，兩者是分開的。為了簡單起見，我們將認證定義為“標識用戶是誰”，授權定義為“確定用戶是什么，不允許做什么”

默認的虛擬主機和用戶

當服務器首次開始運行，并檢測到其數據庫未初始化或被刪除時，它將使用一下資源初始化一個新的數據庫

一個名為 /虛擬主機

一個名為guest的用戶，默認密碼為guest，被授予對/虛擬主機的完全訪問權限

明智的做法是刪除guest用戶或更改密碼，特別是在公共網絡上訪問

默認情況下guest用戶被禁止遠程連接到代理，它只能通過localhost連接。我們創建的其他用戶默認情況下沒有這種限制

如果我們希望允許guest用戶從遠程主機連接，則應將loopback_users配置設置 為 none，如下：

1loopback_users = none

權限如何工作

當一個RabbitMQ客戶端建立到一個服務器的連接時，它指定了一個虛擬主機。此時執行第一級訪問控制，服務器檢查用戶是否有權訪問虛擬主機，否則拒絕連接嘗試

資源(即交換和隊列)在特定虛擬主機內被命名為實體;當對資源執行某些操作時，強制執行第二級訪問控制

RabbitMQ在資源上有配置、寫入、讀取操作
                配置：創建或銷毀資源，或更改其行為
                寫： 寫入消息到資源
                讀： 檢索資源的消息

內存

默認情況下,當RabbitMQ檢測到使用的內存超過40%(由操作系統報告)時，將不會接收任何消息：{vm_memory_high_watermark，0.4}，這是一個安全的默認值

在修改此值應該小心，即使主機是專用的RabbitMQ節點，因為如果沒有足夠的空閑系統內存，將會對操作系統交換造成不利影響，甚至會導致RabbitMQ進程終止

調整默認vm_memory_high_watermark時的一些建議

托管RabbitMQ的節點應始終具有至少128MB的可用內存

推薦的vm_memory_high_watermark范圍是 0.40到0.66

值不要超過0.7。操作系統和文件系統必須至少保留30%的內存，否則性能可能因尋呼而嚴重降級

比如修改配置調整為0.6，編輯rabbitmq.conf

vm_memory_high_watermark.relative = 0.6

磁盤空間

disk_free_limit默認值是50MB

{disk_free_limit，{mem_relative，1.0}}是最小推薦值，和內存的容量一樣大

例如，在專用于具有4GB系統內存的RabbitMQ的主機上，如果可用磁盤空間低于4GB，所有發布者將被阻止，并且不會接收新消息。隊列將需要被排空，通常由消費者，在發布之前將被允許恢復

{disk_free_limit，{mem_relative，1.5}}是一個更安全的產品價值

在具有4GB內存的RabbitMQ節點上，如果可用磁盤空間低于6GB，則所有新消息都將被阻止，直到磁盤警報清除

{disk_free_limit，{mem_relative，2.0}}是最保守的產品價值，我們想不出任何理由使用更高的產品。如果您希望RabbitMQ擁有所有需要的磁盤空間，編輯rabbitmq.conf，比如修改配置調整為2G

disk_free_limit.absolute = 2GB

打開文件句柄限制

保證您的環境至少允許有效的RabbitMQ用戶使用至少50K的開放文件描述符，包括在開發環境中

監控

強烈建議監視系統的幾個方面，從基礎架構和內核度量到RabbitMQ到應用程序級度量。雖然監控需要在時間上進行前期投資，但在提前(或根本)解決問題方面非常有效。

參考zabbix監控(http://blog.thomasvandoren.com/monitoring-rabbitmq-queues-with-zabbix.html)

日志收集

強烈建議所有RabbitMQ節點和應用程序(如果可能的話)的日志都被收集和匯總。日志對于調查不尋常的系統行為至關重要

節點時間同步

節點時間同步

網絡配置

TCP偵聽器配置接口和端口

listeners.tcp.1 = 192.168.1.99:5672

將RabbitMQ配置為僅在IPv4和IPv6上的本地主機上偵聽(雙協議)

listeners.tcp.1 = 127.0.0.1:5672
listeners.tcp.2 = :: 1：5672

TCP緩沖區大小

這是關鍵的可調參數之一。每個TCP連接都有為其分配的緩沖區。一般來說，這些緩沖區越大，每個連接使用的內存就越多，吞吐量越好

在Linux系統上，操作系統默認會自動調整TCP緩沖區大小，通常在80-120KB之間

可以使用rabbit.tcp_listen_options， rabbitmq_mqtt.tcp_listen_options， rabbitmq_amqp1_0.tcp_listen_options和相關的配置項來增加緩沖區大小

以下示例將AMQP 0-9-1連接的TCP緩沖區設置為192 KiB(請注意，將發送和接收緩沖區大小設置為不同的值是危險的，不推薦使用)：即每個連接使用的RAM

tcp_listen_options.backlog = 128
tcp_listen_options.nodelay = true
tcp_listen_options.linger.on = true
tcp_listen_options.linger.timeout = 0
tcp_listen_options.sndbuf = 196608 
tcp_listen_options.recbuf = 196608

有些環境中每個節點持續并發連接數量比吞吐量更重要，因此需要為每個工作負載找到吞吐量和每個連接的RAM使用量之間的最佳值，不建議低于8K

連接握手超時

RabbitMQ的連接握手超時，默認10秒。當客戶端運行在嚴重受限的環境中時，可能需要增加超時。這可以通過rabbit.handshake_timeout(毫秒)完成：

handshake_timeout = 20000

OS級調整

fs.file-MAX                     內核將分配的最大文件數量
net.ipv4.ip_local_port_range    本地IP端口范圍，定義為一對值。范圍必須為并發連接的峰值數量提供足夠的條目
net.ipv4.tcp_tw_reuse           啟用時，允許內核在TIME_WAIT 狀態下重新使用套接字
net.ipv4.tcp_fin_timeout        將此值降低到5-10會減少關閉連接保持TIME_WAIT狀態的時間。推薦用于預計大量并發連接的情況。
net.core.somaxconn              偵聽隊列的大?。ㄍ瑫r建??立多少個連接）。默認值是128.增加到4096或更高，以支持入站連接突發，例如，當客戶端重新連接時
net.ipv4.tcp_max_syn_backlog    記錄的連接請求的最大數量尚未從連接客戶端收到確認。默認值為128，最大值為65535.當優化吞吐量時，建議使用4096和8192開始值
net.ipv4.conf.default.rp_filter 啟用反向路徑過濾。如果IP地址欺騙 不是您的系統所關心的，請將其禁用
 
tcp_listen_options.nodelay      設置為true時，禁用 Nagle的算法。默認是真的。強烈建議大多數用戶
tcp_listen_options.sndbuf       默認值由OS自動調整，通常在現代Linux版本的88 KiB至128 KiB范圍內。增加緩沖區大小可提高每個連接的消費者吞吐量和RAM使用量。減少有相反的效果
tcp_listen_options.recbuf       默認值的效果與rabbit.tcp_listen_options.sndbuf類似，但是對于發布者和協議操作來說一般
tcp_listen_options.backlog      未接受的TCP連接隊列的最大大小。達到這個尺寸時，新的連接將被拒絕。對于具有數千個并發連接和可能的批量客戶端重新連接的環境，設置為4096或更高
tcp_listen_options.keepalive    當設置為true時，啟用TCP保持活動（見上文）。默認是false。對于連接可以長時間閑置（至少10分鐘）的環境有意義，但仍然建議使用心跳
 
TCP Keepalives
    net.ipv4.tcp_keepalive_time = 60
    net.ipv4.tcp_keepalive_intvl = 15
    net.ipv4.tcp_keepalive_probes = 4
    TCP包含一個類似于心跳（aka keepalive）的機制，在消息傳遞協議和上面的網絡核對超時（TCP tickal timeout）中包含TCP保持活動。由于默認設置不足，TCP Keepalive通常不會按照預期的方式工作：需要很長時間（例如，一個小時或更長時間）才能檢測到死亡的對等方。但是，通過調整，它們可以達到與心跳相同的目的，并且有意或無意地清除陳舊的TCP連接，例如選擇不使用心跳的客戶端。下面是TCP keepalive的sysctl配置示例，它認為TCP連接在120秒后死機或不可達（連接空閑60秒后每15秒4次嘗試）：
    在RabbitMQ操作員無法控制應用程序設置或使用的客戶端庫的環境中，TCP Keepalive可以成為有用的附加防御機制。

分區處理策略

在投入生產之前 選擇分區處理策略非常重要

強烈建議不要在網絡分區的環境中部署RabbitMQ集群

以上就是動力節點小編介紹的"rabbitmq部署的生產指南"，希望對大家有幫助，如有疑問，請在線咨詢，有專業老師隨時為您務。