rabbitMQ rascal/amqplib报错 Error: Unexpected close 排查

以下是一些可能导致此 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可以作为一种替代方案。它们不保证您的连接永远不会失败 - 目标仍然是更快地检测此类连接 - 因此您仍然可能会看到失败的套接字写入。