像RabbitMQ這樣的數(shù)據(jù)服務通常有許多可調(diào)參數(shù)。一些配置對開發(fā)有很大的意義，但并不適合生產(chǎn)，本指南旨在為此提供幫助

虛擬主機

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

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

用戶

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

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

權限控制

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

默認的虛擬主機和用戶

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

一個名為 /虛擬主機

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

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

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

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

1loopback_users = none

權限如何工作

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

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

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

內(nèi)存

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

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

調(diào)整默認vm_memory_high_watermark時的一些建議

托管RabbitMQ的節(jié)點應始終具有至少128MB的可用內(nèi)存

推薦的vm_memory_high_watermark范圍是 0.40到0.66

值不要超過0.7。操作系統(tǒng)和文件系統(tǒng)必須至少保留30%的內(nèi)存，否則性能可能因?qū)ず舳鴩乐亟导?/p>

比如修改配置調(diào)整為0.6，編輯rabbitmq.conf

vm_memory_high_watermark.relative = 0.6

磁盤空間

disk_free_limit默認值是50MB

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

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

{disk_free_limit，{mem_relative，1.5}}是一個更安全的產(chǎn)品價值

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

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

disk_free_limit.absolute = 2GB

打開文件句柄限制

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

監(jiān)控

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

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

日志收集

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

節(jié)點時間同步

節(jié)點時間同步

網(wǎng)絡配置

TCP偵聽器配置接口和端口

listeners.tcp.1 = 192.168.1.99:5672

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

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

TCP緩沖區(qū)大小

這是關鍵的可調(diào)參數(shù)之一。每個TCP連接都有為其分配的緩沖區(qū)。一般來說，這些緩沖區(qū)越大，每個連接使用的內(nèi)存就越多，吞吐量越好

在Linux系統(tǒng)上，操作系統(tǒng)默認會自動調(diào)整TCP緩沖區(qū)大小，通常在80-120KB之間

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

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

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

連接握手超時

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

handshake_timeout = 20000

OS級調(diào)整

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

分區(qū)處理策略

在投入生產(chǎn)之前 選擇分區(qū)處理策略非常重要

強烈建議不要在網(wǎng)絡分區(qū)的環(huán)境中部署RabbitMQ集群

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