专注Java教育14年 全国咨询/投诉热线:400-8080-105
动力节点LOGO图
始于2009,口口相传的Java黄埔军校
首页 hot资讯 rabbitmq部署的生产指南

rabbitmq部署的生产指南

更新时间:2023-02-17 16:57:01 来源:动力节点 浏览2928次

像RabbitMQ这样的数据服务通常有许多可调参数。一些配置对开发有很大的意义,但并不适合生产,本指南旨在为此提供帮助

虚拟主机

例如,在单租户环境中,当您的RabbitMQ集群专门为生产中的单个系统供电时,使用默认的虚拟主机(/)是完全正确的

在多租户环境中,为每个租户/环境使用单独的虚拟主机,例如project1_development, project1_production,project2_development和 project2_production等

用户

对于生产环境,请删除默认用户(guest),默认用户只能从本地主机默认连接,因为它具有众所周知的凭据。不要启用远程连接,而应考虑使用具有管理权限和生成密码的单独用户

建议每个应用程序使用一个单独的用户。例如,如果您有一个移动应用程序,一个Web应用程序和一个数据聚合系统,您将有3个独立的用户。这使得许多事情更容易:将客户端连接与应用程序关联

权限控制

认证和授权通常会混淆或互换使用。这是错误的,在RabbitMQ中,两者是分开的。为了简单起见,我们将认证定义为“标识用户是谁”,授权定义为“确定用户是什么,不允许做什么”

默认的虚拟主机和用户

当服务器首次开始运行,并检测到其数据库未初始化或被删除时,它将使用一下资源初始化一个新的数据库

一个名为 /虚拟主机

一个名为guest的用户,默认密码为guest,被授予对/虚拟主机的完全访问权限

明智的做法是删除guest用户或更改密码,特别是在公共网络上访问

默认情况下guest用户被禁止远程连接到代理,它只能通过localhost连接。我们创建的其他用户默认情况下没有这种限制

如果我们希望允许guest用户从远程主机连接,则应将loopback_users配置设置 为 none,如下:

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

以上就是动力节点小编介绍的"rabbitmq部署的生产指南",希望对大家有帮助,如有疑问,请在线咨询,有专业老师随时为您务。

提交申请后,顾问老师会电话与您沟通安排学习

免费课程推荐 >>
技术文档推荐 >>