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