介绍
像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
胡小军 阅读(1644)
评论(0) 编辑 收藏 所属分类:
RabbitMQ