文章目录
- 七、RabbitMQ配置详解
- 八、RabbitMQ优化
- 8.1 加大服务器带宽
- 8.2 加大内存
- 8.3 使用固态硬盘
- 8.4 增加生产者
- 8.5 增加消费者
- 8.6 改网络访问为本地访问
- 8.7 消费端使用长连接
- 8.8 消息不要超过4M
- 九、监控
- 十、常见故障与排查
- 10.1 消费慢
- 10.2 消息丢失
- 10.2.1 生产者消息丢失
- 10.2.2 RabbitMQ消息丢失
- 10.2.3 消费者消息丢失
- 10.3 消息重复消费
- 10.4 报错“error in config file “/etc/rabbitmq/rabbitmq.config” (none): no ending found”
- 10.5 生产者发送消息报错
- 10.6 浏览器打开IP地址，无法访问 RabbitMQ（白屏没有结果）
七、RabbitMQ配置详解
tcp_listeners 监听AMQP连接的端口或主机/对。
Default: [5672]
num_tcp_acceptors Erlang进程的数量，接受TCP监听器的连接数。
Default: 10
handshake_timeout 对AMQP 0-8/0-9/0-9-1握手的最大时间(在套接字连接和SSL握手之后)，以毫秒为间隔
Default: 10000
ssl_listeners 如上所述，用于SSL连接。
Default: []
num_ssl_acceptors 用于接受SSL监听连接的Erlang进程的数量。
Default: 1
ssl_options SSL配置参数. 详情请看 SSL documentation.
Default: []
ssl_handshake_timeout SSL握手超时，以毫秒为间隔。
Default: 5000
vm_memory_high_watermark 触发流控制的内存阈值。详情请看 memory-based flow control.
Default: 0.4
vm_memory_high_watermark_paging_ratio 设置当内存使用超过总内存百分比多少时，队列开始将消息持久化到磁盘以释放内存。 详情请看 memory-based flow control.
Default: 0.5
disk_free_limit RabbitMQ存储数据的分区的磁盘空间限制。当可用的磁盘空间低于这个限制时，就会触发流控制。值可以相对于RAM的总数设置(例如，内存比例，1.0)。该值也可以设置为整数的字节数。或者，单位(例如“50 mb”)。默认情况下，空闲磁盘空间必须超过50MB。详情请看 Disk Alarms.
Default: 50000000
log_levels 控制日志的粒度。该值是一个日志事件类别和日志级别对的列表。
可设置级别：
'none'
'error'
'warning'
'info'
'debug'
以上下一层级别的日志输出均包含上层级别日志输出（如： warning包含warning和error）, none为不输出日志
另外，当前未分类的事件总是记录在日志中
The categories are:
channel - 所有与AMQP通道有关的事件
connection - 对于所有与网络连接有关的事件
federation - 对于所有与 federation有关的事件
mirroring - 对于与镜像队列相关的所有事件
Default: [{connection, info}]
frame_max
框架最大允许大小(以字节为单位)与消费者进行数据交换。设置为0意味着“无限”，但会在一些QPid客户端触发一个bug。
设置更大的值可能会提高吞吐量;
设置较小的值可能会提高延迟。
Default: 131072
channel_max
与消费者进行谈判的最大允许数量。设置为0意味着“无限”。
使用更多的通道会增加代理的内存占用。
Default: 0
channel_operation_timeout 通道操作超时为毫秒(内部使用，由于消息传递协议的差异和限制而不直接暴露于客户机)。
Default: 15000
heartbeat
该值表示服务器在连接中发送的心跳延迟，在几秒钟内。优化框架。如果设置为0，则会禁用心跳。客户端可能不会遵循服务器的建议，请参阅AMQP参考以了解更多细节。
在有大量连接的情况下，禁用心跳可能改善性能，但可能会导致连接在关闭非活动连接的网络设备的出现。
Default: 60 (580 prior to release 3.5.5)
default_vhost 当RabbitMQ创建一个新的数据库时，创建一个虚拟主机。交换amq.rabbitmq.logwill存在于这个虚拟主机中。
Default: <<"/">>
default_user 当RabbitMQ从头创建一个新数据库时，要创建用户名。
Default: <<"guest">>
default_pass 默认用户的密码。
Default: <<"guest">>
default_user_tags 默认用户的标记。
Default: [administrator]
default_permissions 在创建时分配给默认用户的权限。
Default: [<<".*">>, <<".*">>, <<".*">>]
loopback_users
只允许通过环回接口连接到代理的用户列表(即localhost)。 如果您希望允许缺省的来宾用户远程连接，则需要将其更改为 [].
Default: [<<"guest">>]
cluster_nodes 当一个节点开始第一次启动时，将它设置为使集群自动发生。元组的第一个元素是节点试图集群到的节点。第二个元素是磁盘或ram，并确定节点类型。
Default: {[], disc}
server_properties 键值对的列表，在连接上向客户端宣布。
Default: []
collect_statistics 统计数据收集模式。主要与管理插件有关。选项有:
none (不要发布统计数据)
coarse (发出每个队列/每个通道/每个连接统计信息)
fine (发出的每条数据)
通常情况下不需要设置该参数
Default: none
collect_statistics_interval 统计数据收集间隔以毫秒为间隔。 主要相关插件 management plugin.
Default: 5000
management_db_cache_multiplier 管理插件将缓存诸如队列清单之类的代价较高的查询的时间。缓存将把最后一个查询的运行时间乘以这个值，并在此时间内缓存结果。
Default: 5
auth_mechanisms 提供给客户端的SASL身份验证机制。
Default: ['PLAIN', 'AMQPLAIN']
auth_backends
要使用的身份验证和授权后端列表。
rabbit\u auth\u backend\u Internal之外的其他数据库可以通过插件获得。Default: [rabbit_auth_backend_internal]
reverse_dns_lookups 设置为true，让RabbitMQ对客户端连接执行反向DNS查找，并通过rabbitmqctl和管理插件呈现该信息。
Default: false
delegate_count 用于集群内部通信的委托进程的数量。当为多核CPU时可以考虑设置该值
Default: 16
trace_vhosts Used internally by the tracer. 通常情况下不需要设置该参数
Default: []
tcp_listen_options 默认的套接字选项。通常情况下不需要设置该参数
Default:
[{backlog, 128},
{nodelay, true},
{linger, {true,0}},
{exit_on_close, false}]
hipe_compile 设置为true，使用HiPE预编译RabbitMQ的部分，这是Erlang的即时编译器。这将增加服务器的吞吐量，以增加启动时间的成本。
您可能会看到，在启动时延迟几分钟，您的性能会提高20-50%。这些数据是高度工作负载和硬件依赖的。
HiPE支持可能不会编译到您的Erlang安装中。如果不是这样，启用这个选项只会导致一个警告消息被显示，而启动将照常进行。例如，Debian/Ubuntu用户需要安装erlangbase-base-hipe包。
HiPE在某些平台上是不可用的，尤其是Windows。
HiPE在17.5之前就已经知道了erlangp/otp版本的问题。HiPE推荐使用最新的erlangp/otp版本
Default: false
cluster_partition_handling 如何处理网络分区。可用模式:
ignore
pause_minority
{pause_if_all_down, [nodes], ignore | autoheal}
(例: ['rabbit@node1', 'rabbit@node2'])
autoheal
Default: ignore
cluster_keepalive_interval 节点应该多频繁地将keepalive消息发送到其他节点(以毫秒为单位)。请注意，这与netticktime不一样; 错过的keepalive消息不会导致节点被认为挂机。
Default: 10000
queue_index_embed_msgs_below 在消息的字节数中，消息将被直接嵌入到队列索引中。详情请看 persister tuning
Default: 4096
msg_store_index_module 用于队列索引的实现模块。 详情请看 persister tuning
Default: rabbit_msg_store_ets_index
backing_queue_module 队列内容的实现模块。通常情况下不需要设置该参数
Default: rabbit_variable_queue
msg_store_file_size_limit Tunable value for the persister. 通常情况下不需要设置该参数
Default: 16777216
mnesia_table_loading_retry_limit 在等待集群中的Mnesia tables可用时，需要重试的次数。
Default: 10
mnesia_table_loading_retry_timeout 在集群中等待每个重试的时间，以便可用
Default: 30000
queue_index_max_ journal_entries Tunable value for the persister. 通常情况下不需要设置该参数
Default: 65536
queue_master_locator
Queue master定位策略
可用策略:
<<"min-masters">>
<<"client-local">>
<<"random">>
详情请看 documentation on queue master location
Default: <<"client-local">>
lazy_queue_explicit_gc_run_operation_threshold
调优： 只有在内存压力下有延迟队列时。
这是触发垃圾收集器和其他内存减少活动的阈值。一个低的值可以降低性能，一个高的值可以提高性能，但是会导致更高的内存消耗。通常情况下不需要设置该参数
Default: 1000
queue_explicit_gc_run_operation_threshold
调优： 在内存压力较大时。
这是触发垃圾收集器和其他内存减少活动的阈值。一个低的值可以降低性能，一个高的值可以提高性能，但是会导致更高的内存消耗。通常情况下不需要设置该参数
Default: 1000
八、RabbitMQ优化
8.1 加大服务器带宽
访问量大时，较长的数据容易将带宽占满。如服务器上传带宽为10M，则实际上传带宽可认为1M，每秒上传量为1M/1K=1K。如果把带宽加到100M，则每秒上传量为10K。一般情况下，RabbitMq服务器能够接受的每秒写入量为20K-50K（8G内存），因此在带宽在不足200M的时候，加大带宽会产生很明显的提升作用，再往上效果就可能不那么明显了。
8.2 加大内存
RabbitMq的机制是先将消息放在内存中，然后分批写入硬盘。小批量数据的写入基本上都放在内存中，内存数据量过大时会一边把客户端的数据往内存里写，一边将内存里的陈旧数据往硬盘里写，这样会对速度造成较严重的损耗。适度的增加内存，队列将会更多的消息放在内存中，增加系统的处理速度。
8.3 使用固态硬盘
机械硬盘的写入速度较慢，处理大量数据时机械硬盘对性能的损耗十分严重。如果要存放1亿条数据，所需要的硬盘大小为100G，建议采用100-500G固态硬盘。再加上消费端在不断的处理数据，一般待处理的消息能够达到千万级别已经相当不容易了。
8.4 增加生产者
服务器可以建立多个连接，单个生产者往往不能充分利用服务器的潜能，建立多个生产者之后，服务器处理能力将会得到充分利用。一般情况下，一个生产者每秒可以传入1000-5000条消息，在1-10这个范围内，每增加一个生产者，处理速度就会相对单生产者增加一倍。
8.5 增加消费者
消费者增多时，出队速度有明显改善。该方案对于出队速度的影响有限，1-10个进程范围内，相对于单进程只有一倍左右的提升，建议线程开2-5个即可，再多可能影响不大。出现该现象的原因可能是服务器带宽或硬件处理能力有限，消费者增加了也没什么用处。因为没有实际环境测试，此条只列为建议，采用前可以多做实验。
8.6 改网络访问为本地访问
该方案在消费端/生产端与RabbitMq服务器部署在同一台电脑时有用，因为省略了网络传输，大大节省了处理时间。如果消费端/生产端与RabbitMq服务器分开部署，该方案就不能使用了。在代码中将IP地址127.0.0.1改为localhost即可。
8.7 消费端使用长连接
如果每次消费都建立一个连接，无疑将极大的消耗网络与消费端资源，可以只建立一个长链接，所有消息都使用这个长连接来消费。此处需要注意的是，如果长连接出问题，可能会导致队列不能继续消费，需要注意做异常控制。
8.8 消息不要超过4M
消息包大小由1K到10MB，当包大小达到4.5MB时，服务器的性能出现明显的异常，传输率尤其是每秒订阅消息的数量，出现波动，不稳定；同时有一部分订阅者的TCP连接出现断开的现象。可能是客户端底层或者RabbitMQ服务端在进行拆包，组包的时候，出现了明显的压力，而导致异常的发生。
九、监控
可以通过接口 来获取性能指标
http://ip:15672/api/nodes
http://IP:15672/api/queues
http://IP:15672/api/overview
通过rabbitmq_exporter来获取RabbitMQ监控指标
获取节点信息的API：
GET /api/nodes/{node} 返回单个节点的状态
GET /api/nodes 返回所有集群成员的统计信息
| 指标 | JSON field name |
|---|---|
| 使用的内存总量 | memory used mem_used |
| 内存使用阈值 | mem_limit |
| 当内存使用超过阈值时将触发报警 | memory alarm mem_alarm |
| 剩余磁盘空间阈值 | disk_free_limit |
| 当空闲磁盘空间低于配置的限制时， 将触发报警 | disk_free_alarm |
| 可用文件描述符总数 | fd_total |
| 当前使用的文件描述符 | fd_used |
| 尝试打开的文件描述符数量 | io_file_handle_open_attempt_count |
| socket可用 | sockets_total |
| 已经使用的socket数量 | sockets_used |
| Message store disk reads | message_stats.disk_reads |
| Message store disk writes | message_stats.disk_writes |
| Inter-node communication links | cluster_links |
| GC runs | gc_num |
| gc回收的字节 | gc_bytes_reclaimed |
| erlang进程限制 | proc_total |
| 已经使用erlang进程 | proc_used |
| 正在运行的队列 | run_queue |
可以从任一节点获取集群监控数据
API：GET /api/overview
| 指标 | JSON field name |
|---|---|
| 集群名称 | cluster_name |
| 集群范围的消息速率 | message_stats |
| 连接总数 | object_totals.connections |
| channel总数 | object_totals.channels |
| 队列总数 | object_totals.queues |
| 消费者总数 | object_totals.consumers |
| 消息总数（ready+unacked） | queue_totals.messages |
| 准备交付的消息数量 | queue_totals.messages_ready |
| 未确认的消息数量 | queue_totals.messages_unacknowledged |
| 最近发布的消息数量 | message_stats.publish |
| 消息发布的速率 | message_stats.publish_details.rate |
| 最近发送给消费者的消息数量 | message_stats.deliver_get |
| 消息交付速率 | message_stats.deliver_get.rate |
单个队列监控API地址: GET /api/queues/{vhost}/{qname}
| 指标 | JSON field name |
|---|---|
| 内存 | memory |
| 消息总数（ready+unacknowledged） | messages |
| 准备交付的消息数量 | messages_ready |
| 未确认的消息数量 | messages_unacknowledged |
| 最近发布的消息数量 | message_stats.publish |
| 消息发布速度 | message_stats.publish_details.rate |
| 最近交付的消息数量 | message_stats.deliver_get |
| 消息交付速度 | message_stats.deliver_get.rate |
| 其他消息状态 | this document message_stats |
整理监控指标情况
| 监控项 | 指标名称 | 阈值 |
|---|---|---|
| rabbitmq节点状态 | rabbitmq-status | != 1 紧急 |
| rabbitmq节点内存使用率 | rabbitmq-node_mem_used | > 0.8中度 >0.9严重 |
| rabbitmq文件句柄数使用率 | rabbitmq_fd_used | > 0.8中度 >0.9严重 |
| rabbitmq堆积消息监控 | rabbitmq_queue_messages_unack | > 500中度 > 1000严重 |
| rabbitmq推送错误监控 | rabbitmq_failed_to_publish_total | >5中度 |
| rabbitmq可消费消息数监控 | rabbitmq_queue_messages_ready | > 5000中度 |
| rabbitmq推送消息监控 | rabbitmq_queue_messages_published_total | ==0中度 |
| rabbitmq消息投递监控 | rabbitmq_queue_messages_delivered_total | ==0中度 |
| rabbitmq消息连接恢复 | rabbitmq_connection_recovery_total | >10中度 |
| rabbitmq消息连接数 | rabbitmq_connections | ==0严重 |
| rabbitmq通道 | rabbitmq_channel | ==0严重 |
| rabbitmq消费者 | rabbitmq_consumers | ==0严重 |
| rabbitmq的sockets使用率 | rabbitmq_sockets_used | > 0.8中度 >0.9严重 |
十、常见故障与排查
RabbitMQ注意小计（故障恢复提示）：
- 保证集群中至少有一个磁盘类型的节点以防数据丢失，在更改节点类型时尤其要注意。
- 若整个集群被停掉了，应保证最后一个down掉的节点被最先启动，若不能则要使用forget_cluster_node命令将其移出集群。
- 若集群中节点几乎同时以不可控的方式down 了，此时再其中一个节点使用force_boot 命令重启节点。
- 如果加入集群后，意外关闭等造成rabbitmq-server启动不成功，可以尝试一下步骤：/var/lib/rabbitmq/mnesia 目录下存在rabbit@localhost.pid、rabbit@localhost、rabbit@localhost-plugins-expand，删除这3项后，并且删除 /var/lib/rabbitmq/ 目录下 .erlang.cookie和erl_crash.dump 再使用systemctl start rabbitmq-server启动
10.1 消费慢
问题分析：
可以看到RabbitMQ的内存 占用占用已经使用了7.8G 允许的值为 .6G左右
因为 vm_memory_high_watermark 值设置的是0.4 也就是物理内存的40% ；服务器为16G * 40% = 6.4G
一般在产生的原因是长期的生产者发送速率大于消费者消费速率导致. 触发了RabbitMQ 的流控；
解决方案：
- 增加消费者端的消费能力,或者增加消费者(根本解决)
- 控制消息产生者端的发送速率(不太现实)
- 增加mq的内存(治标不治本)
10.2 消息丢失
这个是RabbitMQ最常见的问题,RabbitMQ丢失分三种情况,生产者消息丢失,RabbitMQ消息丢失,消费者消息丢失。
10.2.1 生产者消息丢失
生产者在发送消息给RabbitMQ,在中途有可能因为网络问题导致消息丢失,我们可以选择RabbitMQ提供的事务,也可以用confirm模式,就是生产者确认。
事务:
channel.tsSelect开启事务;
channel.txRollback出现问题事务回滚
channel.txCommit成功后提交事务
confirm模式:
生产者发送消息,每个消息分配一个id,如果RabbitMQ接收到消息返回ack,如果没有收到放回nack,这个时候生产者只需要重新发送这个消息即可,可以结合这个机制在内存里设置消息id的状态,多长时间没有f返回ack就是失败,重新发送消息。
事务和confirm对比:
事务是属于同步的,在你提交一个事务会阻塞在那里,其他的消息是不能继续发送的,这样很容易影响性能,而confirm是异步的就是发送完我可以继续发送另一条消息,在正常使用中推荐使用confirm模式
10.2.2 RabbitMQ消息丢失
RabbitMQ数据丢失,可以用持久化分为两个步骤:
-
首选创建queue的时候将其设置为持久化,这样可以保证RabbitMQ持久化queue的元数据,而不会持久化queue的数据,
-
第二步将消息的deliveryMode设置为2,就是将消息设置为持久化,此时消息就会持久化到磁盘上,即使RabbitMQ重启,也会从磁盘上恢复queue,恢复queue里的数据跟生产者的confirm配合,如过持久化到磁盘上再返回ack,如果还没持久化就RabbitMQ挂掉了,生产者没有收到ack,还是会重新发送消息。
10.2.3 消费者消息丢失
消费者有可能因为刚接到消息还没有处理就重启了,但是RabbitMQ以为他处理了,这样就会导致消息丢失,合理的解决方案是关闭自动ack,可以通过api来进行调用,等自己的代码处理完成之后,可以ack,这样即使你没有消费RabbitMQ也知道你是没有去消费的,这个时候RabbitMQ可以把消息交给其他的consumer进行消费,避免消息丢失。
10.3 消息重复消费
**出现原因：**消费者消息消息的时候，MQ没有收到消息的ack应答。
场景：
- 消费者消费消息后没有ack。
- 消费者在消费消息后，ack时网络异常。
解决步骤：
- 消费者消费后，记录通过缓存记录消息的消费标识，消息id如redis的setnx
- 如果消费成功且ack成功，则删除记录的消息标记。
- 如果ack失败，消息下次被消费消息时候，先去查询消息的消费标识，已经消费则直接ack，未消费则继续消费。
10.4 报错“error in config file “/etc/rabbitmq/rabbitmq.config” (none): no ending found”
rabbitmq config的配置相关的官方文档： http://www.rabbitmq.com/configure.html
官方给出的一个示例配置： https://github.com/rabbitmq/rabbitmq-server/blob/v3.8.x/deps/rabbit/docs/rabbitmq.conf.example
拷贝以上实例文档到对应的rabbitmq的安装目录下的文件：/etc/rabbitmq , 取名配置文件名称为 rabbitmq.config，重启rabbit，那么当前文件就为当前rabbit所使用。
10.5 生产者发送消息报错
channel is already closed due to channel error; protocol method: #method<channel.close>(reply-code=404, reply-text=NOT_FOUND - home node ‘rabbit@xxx’ of durable queue ‘xxx_queue’ in vhost ‘/’ is down or inaccessible, class-id=50, method-id=10)
生产者连接不上vhost’/'，看报错像是服务端有问题，经排查后发现，发现服务集群有一个节点满了，导致连接到这个节点的Connection都出问题了。
解决方案：添加节点，重启生产者服务。
10.6 浏览器打开IP地址，无法访问 RabbitMQ（白屏没有结果）
服务器对应的安全组15672端口没有开启（入规则），导致浏览器无法访问到服务器的任何内容。
