直播网站怎么做的,怎样做网站卖自己的产品,广州网站建设程序开发,万维网包括哪些网站以下是一些可能导致此 RabbitMQ 客户端或任何其他 RabbitMQ 客户端中的套接字读取或写入失败的常见场景
1.错过#xff08;客户端#xff09;心跳
第一个常见原因是RabbitMQ 检测到心跳丢失。发生这种情况时#xff0c;RabbitMQ 将添加一个有关它的日志条目#xff0c;然…以下是一些可能导致此 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/rabbitecmaster.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_time60 调整KeepAlive参数
sysctl -w net.ipv4.tcp_keepalive_intvl10
sysctl -w net.ipv4.tcp_keepalive_probes6 连接恢复
自动连接恢复是多个 RabbitMQ 客户端多年来支持的功能例如Java 客户端和Bunny。这被认为是 RabbitMQ 团队已经解决的问题
至少就恢复拓扑时的一般方法和恢复步骤顺序而言是这样。考虑遵循这些客户文档中概述的步骤而不是重新发明自己的步骤。
