From：https://www.rabbitmq.com/heartbeats.html

网络是不可靠的。被中断的TCP连接需要较长时间才能被操作系统检测到（linux默认情况下是11分钟）。AMQP 0-9-1提供heartbeat机制以保证应用层发现中断的连接或者没有响应的对端。heartbeat机制也可以解决在稳定网络环境下，一些设备会中断空闲了一段时间的TCP连接。

TCP连接保持机制与heartbeat机制目的类似而且非常有用。但这要求对内核进行调整以适应大多数操作系统及发行版本。

1. heartbeat超时时间

这个值在client及rabbitmq进行协商，客户端必须配置为请求心跳。

默认情况下，broker及客户端都会尝试协调心跳。当两端配置都为非0值时，二者中较小的那个配置值生效。如果一端配置为0来关闭心跳，而对端为非0值，那么非0值生效。

timeout单位为秒，默认情况下是60秒。在比较老的版本中，默认是500秒。

2. 心跳帧

心跳帧发送间隔时间为heartbeat_time/2。有时候这个值配置为heartbeat_interval。当丢失掉2个心跳后，会认为对端是不可达的。不同的客户端的处理方式是不一样的，但TCP连接会被关闭。当客户端检测到rabbitmq节点是由于心跳问题不可达时，会重连。

不要混淆心跳timeout值及心跳间隔。RabbitMQ配置公开了超时值，官方支持的客户端也是如此。但某些客户端可能会暴露间隔，这会造成一些混淆。

任何有效的流量（比如协议操作，消息发布，消息确认等）都会被认为是一个有效的心跳。不论是否有其他流量，客户端都会选择发送心跳帧；但有些客户端只在有必要的时候发送。

3. 禁止心跳

可以通过在client及sever设置timeout interval为0来禁止心跳
也可以选择将心跳值设置为非常大，如1800s来有效的禁用心跳。
除非是有TCP保持机制来代替此方案，否则不建议禁用心跳。

4.低超时时间及误报

如果将心跳时间设置的过低，会在短暂的网络拥塞或流量控制的清下下导致误报。在选择超时时间时，这也应该作为一个考虑因素。

从用户反馈的多年的经验值及客户端的maintainer的建议来看，低于5s都容易发生误报。对于大多数环境5s到20s之间是最佳的。

5.TCP保持

TCP保持机制与消息协议中心跳机制类似以及集群中的net tick timeout类似。TCP默认配置不适合于消息协议。但通过调整，在不启用心跳或心跳值设置不合理的场景下，这可以作为额外的保护机制。

在极少数情况下，仅有心跳机制是不够的（当客户端使用的消息协议不支持心跳），TCP保持必须被配置为合理的比较低的值。

TCP心跳保持覆盖了节点上所有TCP连接，所有入和出的流量。

通过将TCP keepalive配置为比较低的系统特定值，也可以使用TCP keepalive代替心跳。 在这种情况下，可以禁用心跳。 这种方法的主要好处是，无论使用何种协议和客户端库，计算机上的所有TCP连接都将使用相同的值。

6. 心跳和TCP代理

一些网络工具如Haproxy及设备如硬件负载均衡会在这些连接在一定时间段内没有活动时，会关闭空闲的TCP连接。大多数时间这是不可取的。

当启用心跳时，会带来周期性的轻网络流量。因此，心跳具有保护客户端连接的作用，这些客户端可以在一段时间内空闲，以防止代理或负载均衡设备过早的关闭。

当心跳超时时间为30s时，产生轻网络流量的周期为15s。5到15s内范围内的活动，可以满足大多数常用代理或负载均衡设备的默认值。

7. 故障排除

RabbitMQ节点会在日志中记录”由于心跳丢失关闭连接日志”。所有官方支持的客户端库也会打印类似日志。查看客户端及服务端日志，是故障排查的第一个步骤。

可能需要检查打开或来自节点的连接，其状态，来源，用户名和有效心跳超时值。网络故障排除指南概述了可用于提供帮助的工具