RabbitMQ生产部署指南
像RabbitMQ这样的数据服务通常有许多可调参数。一些配置对开发有很大的意义，但并不适合生产，本指南旨在为此提供帮助
虚拟主机
例如，在单租户环境中，当您的RabbitMQ集群专门为生产中的单个系统供电时，使用默认的虚拟主机（/）是完全正确的
在多租户环境中，为每个租户/环境使用单独的虚拟主机，例如project1_development， project1_production，project2_development和 project2_production等
用户
对于生产环境，请删除默认用户（guest）,默认用户只能从本地主机默认连接，因为它具有众所周知的凭据。不要启用远程连接，而应考虑使用具有管理权限和生成密码的单独用户
建议每个应用程序使用一个单独的用户。例如，如果您有一个移动应用程序，一个Web应用程序和一个数据聚合系统，您将有3个独立的用户。这使得许多事情更容易：将客户端连接与应用程序关联
权限控制
认证和授权通常会混淆或互换使用。这是错误的，在RabbitMQ中，两者是分开的。为了简单起见，我们将认证定义为“标识用户是谁”，授权定义为“确定用户是什么，不允许做什么”
默认的虚拟主机和用户
当服务器首次开始运行，并检测到其数据库未初始化或被删除时，它将使用一下资源初始化一个新的数据库
一个名为 /虚拟主机
一个名为guest的用户，默认密码为guest，被授予对/虚拟主机的完全访问权限
明智的做法是删除guest用户或更改密码，特别是在公共网络上访问
默认情况下guest用户被禁止远程连接到代理，它只能通过localhost连接。我们创建的其他用户默认情况下没有这种限制
如果我们希望允许guest用户从远程主机连接，则应将loopback_users配置设置 为 none，如下：
loopback_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 侦听队列的大小（同时建立多少个连接）。默认值是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集群
