以下是一些可能导致此 RabbitMQ 客户端或任何其他 RabbitMQ 客户端中的套接字读取或写入失败的常见场景
1.错过(客户端)心跳
第一个常见原因是RabbitMQ 检测到心跳丢失。发生这种情况时,RabbitMQ 将添加一个有关它的日志条目,然后根据规范要求关闭连接。
以下是 RabbitMQ 日志中丢失的客户端心跳的样子:
2017-09-26 08:04:53.596 [warning] <0.2375.628> closing AMQP connection <0.2375.628> (127.0.0.1:54720 -> 127.0.0.1:5672):
missed heartbeats from client, timeout: 8s
对于I/O操作与使用者操作不并发的客户端(我相信这里是这样的),如果使用者操作花费的时间超过检测信号超时,RabbitMQ将检测到错过的客户端检测信号。禁用心跳可能有所帮助,但我不建议这样做。
如果您禁用心跳,请确保您的内核配置为使用合理的TCP keepalive 设置,默认情况下并非所有流行的 Linux 发行版都是如此
rabbit心跳
查看rabbitmq日志 /var/log/rabbitmq/rabbit@ecmaster.log
closing AMQP connection <0.4893.0> (127.0.0.1:58310 -> 127.0.0.1:5672):
missed heartbeats from client, timeout: 10s
web控制台 connection界面中可查看hearbeats 的值。
client与rabbitqm-server协商心跳检查时间(server默认为60s),
如果任一值为0,则使用两者中较大的值,否则使用两者中较小的值。
零值表示对等方建议完全禁用心跳。要禁用心跳,两个对等方都必须选择加入并使用值0。强烈建议不要这样做,除非已知环境在每个主机上使用 TCP keepalive(见第5条)。也强烈建议不要使用非常低的值。
rascal 可以调整配置文件的connection.options.heartbeat来配置心跳时间,默认为10。
rabbitmq-server可在/etc/rabbitmq/rabbitmq.conf(不存在就新建) 调整heartbeat 配置项 heartbeat = 60 修改后重启systemctl restart rabbitmq-server.service 即可
2.中介关闭“非活动”TCP 连接
第二个常见原因:TCP 连接被中介(例如代理或负载均衡器)关闭。
如果您在 RabbitMQ 日志中看到以下内容
2017-09-26 08:08:39.659 [warning] <0.23042.628> closing AMQP connection <0.23042.628> (127.0.0.1:54792 -> 127.0.0.1:5672, vhost: '/', user: 'guest'):
client unexpectedly closed TCP connection
这意味着客户端的 TCP 连接在 AMQP 0-9-1(该客户端的)连接之前关闭。有时这是无害的,意味着应用程序在终止之前不会关闭连接。不太好,但没有功能上的缺点。此类日志条目还可能表明客户端应用程序进程失败(与此线程无关),或者很常见的是,代理关闭了连接。代理和负载均衡器具有 TCP 连接不活动超时,心跳指南中提到)。它们的长度通常为 30 秒到 5 m。
虽然心跳和 TCP keepalive 的设计目的不是为了解决不幸的负载均衡器或代理设置,但通过产生定期的网络流量,它们恰好可以做到这一点。
3.其他连接生命周期日志条目
下面的条目不一定与失败的套接字写入相关,但值得解释它们,
因为它们在解决连接相关问题时非常有用(并且可能会被误解)。
如果您在 RabbitMQ 日志中仅看到以下内容:closing AMQP connection <0.13219.456> (153.x.x.x:56468 -> 185.x.x.x:5672)
(没有任何提及或心跳、意外关闭的 TCP 连接、连接错误或 RabbitMQ 端的任何超时套接字写入),这意味着客户端连接已干净且成功关闭,并且是应用程序发起的。
{writer,send_failed,{error,timeout}}
意味着 RabbitMQ 尝试写入套接字,但该操作超时。如果您在客户端写入失败的同时看到此情况,则意味着连接出现故障,但未启用心跳或 TCP keepalive,并且未更快地检测到它。
4.其他可能的原因?TCP 连接可能会失败。
在大多数其他情况下,失败的套接字写入就是失败的套接字写入。网络连接可能会失败或性能下降。这个客户端或 RabbitMQ 无法避免这一点。这正是 AMQP 0-9-1、STOMP、MQTT 等消息传递协议引入heartbeats的原因,而在该客户端中,heartbeats 并不能很好地实现其目的。
5.一种的替代方案:TCP Keepalive
TCP keepalive可以作为一种替代方案。 它们不保证您的连接永远不会失败 - 目标仍然是更快地检测此类连接 - 因此您仍然可能会看到失败的套接字写入。
TCP KeepAlive
TCP 包含一种与上面介绍的消息传递协议中的心跳(又名保活)类似的机制:TCP 保活。由于默认值不充分,不能假定 TCP keepalive 适合消息传递协议。但是,通过适当的调整,在无法期望应用程序启用检测信号或使用合理值的环境中,它们可以作为额外的防御机制
在某些极少数情况下,仅靠心跳是不够的(例如,当涉及的连接使用不具有某种心跳机制的协议时),必须将 TCP keepalive 配置为使用相当低的超时值。
通过将 TCP keepalive 配置为较低的系统特定值,也可以使用 TCP keepalive 来代替心跳。在这种情况下,可以停用心跳。这种方法的主要好处是,无论使用什么协议和客户端库,计算机上的所有 TCP 连接都将使用相同的值。
TCP协议通过KeepAlive机制判断是应用程序掉线了还是确实没有数据传输,当超过一段时间之后,TCP自动发送一个数据为空的报文给对方,如果对方回应了这个报文,说明对方还在线,连接可以继续保持,如果对方没有报文返回,并且重试了多次之后则认为连接丢失,没有必要保持连接。
KeepAlive并不是默认开启的,在Linux系统上没有一个全局的选项去开启TCP的KeepAlive。需要开启KeepAlive的应用必须在TCP的socket中单独开启。Linux Kernel有三个选项影响到KeepAlive的行为:
sysctl -a|grep keepalive //查看数值
net.ipv4.tcpkeepalivetime = 7200
net.ipv4.tcpkeepaliveintvl = 75
net.ipv4.tcpkeepaliveprobes = 9
tcpkeepalivetime的单位是秒,表示TCP连接在多少秒之后没有数据报文传输启动探测报文; 60
tcpkeepaliveintvl单位是也秒,表示前一个探测报文和后一个探测报文之间的时间间隔,
tcpkeepaliveprobes表示探测的次数。
sysctl -w net.ipv4.tcp_keepalive_time=60 调整KeepAlive参数
sysctl -w net.ipv4.tcp_keepalive_intvl=10
sysctl -w net.ipv4.tcp_keepalive_probes=6
连接恢复
自动连接恢复是多个 RabbitMQ 客户端多年来支持的功能,例如Java 客户端和Bunny。这被认为是 RabbitMQ 团队已经解决的问题,文章来源:https://www.toymoban.com/news/detail-763878.html
至少就恢复拓扑时的一般方法和恢复步骤顺序而言是这样。考虑遵循这些客户文档中概述的步骤,而不是重新发明自己的步骤。文章来源地址https://www.toymoban.com/news/detail-763878.html
到了这里,关于rabbitMQ rascal/amqplib报错 Error: Unexpected close 排查的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!