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集群