介紹
像RabbitMQ這樣的數據服務經常有許多的可調參數．某些配置對于開發環境來說是意義的，但卻不適合產品環境. 單個配置不能滿足每種使用情況. 因此，在進入產品環境時，評估配置是很重要的. 這就是本指南提供幫助的目的．
虛擬主機，用戶，權限
Virtual Hosts
在單租戶環境中，例如，當RabbitMQ在產品環境中只致力于為某單個系統服務時，使用默認虛擬主機 (/)是非常好的.
在多租戶環境中，為每個租戶／環境使用單獨的虛擬主機，如：project1_development, project1_production, project2_development, project2_production, 等等.
用戶
在產品環境中，刪除默認用戶(guest). 默認情況下，默認用戶只能通過本地來連接, 因為它有眾所周的憑證.為了不啟用遠程連接,可考慮使用帶有administrative權限和生成密碼的獨立用戶來代替
強烈建議在每個程序中使用單獨的用戶,例如，如果你有一個mobile app, 一個Web app, 和一個數據聚合系統, 你最好有３個獨立的用戶. 這會使許多事情變得更簡單:
- 使 client 連接與程序相關聯
- 使用細粒度的權限
- 憑據翻滾(如. 周期性地或遭到破壞的情況下)
如果有許多相同應用程序的實例，有一個更好安全性權衡（每一個實例的憑據）和方便的配置（共享一些或所有實例之間的一組憑據）。物聯網的應用涉及很多客戶執行相同或相似的功能，有固定的IP地址，它可以使用X509證書或源IP地址范圍驗證。
資源限制
內存
默認情況下， RabbitMQ會使用可用RAM的40%． 這專門針對于那些運行RabbitMQ的節點，通常情況下，提高此限制是合理的. 然而，應注意的是，操作系統和文件系統的緩存也需要內存來運行。如果不這樣做，會由于操作系統交換導致嚴重的吞吐量下降，甚至導致操作系統會終止RabbitMQ過程的運行。
- 至少有128 MB
- 當RAM達到4GB時，可配置為75%的RAM限制
- 當RAM達到4GB－8GB時，可配置為80%的RAM限制
- 當RAM達到8GB－16GB時，可配置為85%的RAM限制
- 當RAM大于16GB時，可配置為90%的RAM限制
高于0.9的值是很危險的，不推薦配置
可用磁盤空間
必要的可用磁盤空間可防止disk space alarms.(磁盤空間報警) ．默認情況下，RabbitMQ始終需要 50 MiB的可用磁盤空間.在大多數Linux發行者，根據開發者的經驗，可將放置到小分區的/var 目錄下. 然而，對于產品環境來說，這不是一個推薦值, 因為它們可能明顯的更高的RAM 限制. 下面是一些基本的指導方針，如何確定有多少空閑磁盤空間是推薦的: - 至少有2 GB
- 當限制為1到8GB的RAM時，可配置為RAM限制的50％
- 當限制為8到32GB的RAM時，可配置為RAM限制的40%
- 當限制超過32GB的RAM時，可配置為RAM限制的30%
rabbit.disk_free_limit 配置可通過 {mem_relative, N}來完成，使其相對于RAM限制的百分比來計算. 例如, 使用{mem_relative, 0.5} 設為50%, {mem_relative, 0.25}設為25%等等.
打開文件句柄限制
操作系統限制了并發打開的文件句柄的最大數量，其中包括網絡套接字。確保您的限制設置得足夠高，以允許預期數量的并發連接和隊列。
對于有效RabbitMQ用戶，確保你的環境允許至少50K的打開文件描述符，包括開發環境。
作為經驗法則,并發連接數的95%乘以２再加上隊列的總數可以計算出打開文件句柄限制( multiple the 95th percentile number of concurrent connections by 2 and add total number of queues to calculate recommended open file handle limit). 值高于500K也是恰當地，它不會消耗太多的硬件資源，因此建議在生產環境中設置. 查看Networking guide 來了解更多信息. 安全注意事項
用戶和權限
查看vhosts, users, 和 證書章節.
Erlang Cookie
在Linux 和BSD 系統中, 有必要限制只有運行RabbitMQ和rabbitmqctl工具的用戶才能訪問Erlang cookie. TLS
雖然RabbitMQ試圖提供一個默認的安全TLS 配置 (如．SSLv3是禁用的), 我們推薦評估TLS 版本和密碼套件. 請參考TLS guide 了解更多信息. 網絡配置
自動連接恢復
某些client libraries, 例如 Java, .NET, 和 Ruby, 在網絡失敗后，支持自動連接恢復．如果client提供了這種功能，建議使用它來代替你自己的恢復機制. 集群化考慮
集群大小
當確定集群大小時，需要重點考慮下面的幾個因素：
- 希望的吞吐量
- 希望的復制( mirrors的數目)
- 數據局部性
因為客戶端可以連接到任何節點，RabbitMQ可能需要進行集群間消息路由和內部操作。嘗試使消費者和生產者連接到同一個節點，如果可能的話：這將減少節點間的流量。 使消費者連接到持有隊列的master上(可使用HTTP API進行推斷)，也是有幫助的.當考慮到數據局部性時，總的集群吞吐量可以達到不平凡的量。 對于大多數環境中，鏡像超過一半的群集節點是足夠的。建議使用一個奇數的節點（3，5，等等）的集群。
分區處理策略
posted on 2016-07-30 16:47
胡小軍 閱讀(1658)
評論(0) 編輯 收藏 所屬分類:
RabbitMQ