RabbitMQ-官方指南－产品清单
原文：
http://www.rabbitmq.com/production-checklist.html
介绍
像RabbitMQ这样的数据服务经常有许多的可调参数．某些配置对于开发环境来说是意义的，但却不适合产品环境. 单个配置不能满足每种使用情况. 因此，在进入产品环境时，评估配置是很重要的. 这就是本指南提供帮助的目的．
虚拟主机，用户，权限
Virtual Hosts
在单租户环境中，例如，当RabbitMQ在产品环境中只致力于为某单个系统服务时，使用默认虚拟主机 (
/
)是非常好的.
在多租户环境中，为每个租户／环境使用单独的虚拟主机，如：
project1_development
,
project1_production
,
project2_development
,
project2_production
, 等等.
用户
在产品环境中，删除默认用户(
guest
). 默认情况下，默认用户只能通过本地来连接, 因为它有众所周的凭证.为了不启用远程连接,可考虑使用带有administrative权限和生成密码的独立用户来代替
强烈建议在每个程序中使用单独的用户,例如，如果你有一个mobile app, 一个Web app, 和一个数据聚合系统, 你最好有３个独立的用户. 这会使许多事情变得更简单:
- 使 client 连接与程序相关联
- 使用细粒度的权限
- 凭据翻滚(如. 周期性地或遭到破坏的情况下)
如果有许多相同应用程序的实例，有一个更好安全性权衡（每一个实例的凭据）和方便的配置（共享一些或所有实例之间的一组凭据）。物联网的应用涉及很多客户执行相同或相似的功能，有固定的IP地址，它可以使用X509证书或源IP地址范围验证。
资源限制
当消费者跟不上的时候，RabbitMQ 使用
Resource-driven alarms
(资源驱动报警)来压制(throttle）发布者. 在进入生产之前评估资源限制配置是重要的。
内存
默认情况下， RabbitMQ会使用可用RAM的40%． 这专门针对于那些运行RabbitMQ的节点，通常情况下，提高此限制是合理的. 然而，应注意的是，操作系统和文件系统的缓存也需要内存来运行。如果不这样做，会由于操作系统交换导致严重的吞吐量下降，甚至导致操作系统会终止RabbitMQ过程的运行。
下面是一些基本的指导方针，用于确定推荐的
RAM limit
:
- 至少有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
如果有可能，我们建议使用
Ｔ
LS connections
， 至少要加密通信. Peer验证（身份验证）也被推荐 . 开发和QA 环境可使用
self-signed TLS certificates
. 当RabbitMQ和所有程序运行在可信网络或隔离(使用像VMware NSX技术)环境中时，自签名证书可以应用于产品环境．
虽然RabbitMQ试图提供一个默认的安全TLS 配置 (如．SSLv3是禁用的), 我们推荐评估TLS 版本和密码套件. 请参考
TLS guide
了解更多信息.
网络配置
产品环境需要调整网络配置．请参考
Networking Guide
来了解细节.
自动连接恢复
某些client libraries, 例如
Java
,
.NET
, 和
Ruby
, 在网络失败后，支持自动连接恢复．如果client提供了这种功能，建议使用它来代替你自己的恢复机制.
集群化考虑
集群大小
当确定集群大小时，需要重点考虑下面的几个因素：
- 希望的吞吐量
- 希望的复制( mirrors的数目)
- 数据局部性
因为客户端可以连接到任何节点，RabbitMQ可能需要进行集群间消息路由和内部操作。尝试使消费者和生产者连接到同一个节点，如果可能的话：这将减少节点间的流量。 使消费者连接到持有队列的master上(可使用HTTP API进行推断)，也是有帮助的.
当考虑到数据局部性时，总的集群吞吐量可以达到不平凡的量
。
对于大多数环境中，镜像超过一半的群集节点是足够的。建议使用一个奇数的节点（3，5，等等）的集群。
分区处理策略
在用于产品环境之前，挑选
partition handling strategy
是很重要的.
有疑问时，使用theautoheal策略。