以下是一些可能导致此 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 团队已经解决的问题，
至少就恢复拓扑时的一般方法和恢复步骤顺序而言是这样。考虑遵循这些客户文档中概述的步骤，而不是重新发明自己的步骤。
