从 RabbitMQ 官网的 heartbeats 翻译。
简介
网络在很多情况下会失败，有时情况很微妙（比如 丢包率很高）。操作系统检测到 TCP 断开是一个适中的时间（在 Linux 中默认时长是 11 分钟）。AMQP 0-9-1 提供心跳检测功能来确保应用层及时发现中断的连接（或者是完全没有工作的连接）。 心跳检测还能保护连接不会在一段时间内没有活动而被终止。
心跳超时间隔
心跳 timeout 值决定了 TCP 相互连接的最大时间，超过这个时间，该连接将被 RabbitMQ 和 客户端当作不可到达。这个值是在 RabbitMQ 服务器和客户端连接的时候协商的。客户端需要配置请求心跳检测。RabbotMQ 3.0 及以上的版本中，RabbitMQ 默认设置与客户端之间的心跳时长为 60 秒（3.5.5 版本之前的默认值为 580）。
心跳帧每隔 timeout/2 时间会发送一次。连续两次心跳失败后，连接将会当作不可到达。不同客户端对此的表现不同，但是 TCP 连接都会关闭。当客户端检测到 RabbitMQ 服务节点不可到达，它需要重新发起连接。
任何连接数据交换（例如 协议操作、发布消息、消息确认）都会计入有效的心跳。客户端可能也会发送心跳包，在连接中有其他数据交换，但有些只在需要时发送心跳包。
可以设置 timeout 为 0 来禁用心跳检测功能。不推荐这么做。
Java 客户端中开启心跳
为了在 Java 客户端设置心跳 timeout 时间，需要在创建连接之前通过 ConnectionFactory#setRequestedHeartbeat 设置 timeout 值：
ConnectionFactory cf = new ConnectionFactory();
// set the heartbeat timeout to 60 seconds
cf.setRequestedHeartbeat(60);
注意，如果 RabbitMQ 服务器配置了非零的心跳 timeout 时间（以 3.6.x 开头的版本都有默认设置），客户端设置的时间智能小于这个时长，而不能大于这个时长。
.Net 客户端中开启心跳
为了在 .NET 客户端设置心跳 timeout 时间，需要在创建连接之前通过 ConnectionFactory.RequestedHeartbeat 设置 timeout 值：
var cf = new ConnectionFactory();
// set the heartbeat timeout to 60 seconds
cf.RequestedHeartbeat = 60;
低超时间隔和误报
设置心跳 timeout 时长过段会导致误报（正常的客户端连接会被误报为不可到达）。可能会因为瞬间的网络拥堵、短暂的服务器流量控制，或者其他原因。在设置 timeout 值时需要考虑这些因素。
用户和客户端包维护者多年的反馈建议。timeout 值小于 5 秒很可能导致误报，小于等于 1 秒更有可能误报，在 5 到 20 之间是大多数环境适合的值。
STOMP 中的心跳
STOMP 1.2 中支持心跳检测。在 STOMP 协议中，心跳检测的 timeouts 值可以是不对称性的：以就是说，客户端和服务端可以使用不同的 timeouts 值。RabbitMQ STOMP 插件完整支持这个特性。
心跳检测在 STOMP 中是可选的。为了启动它，在连接的时候需要设置 heart-beat 头信息。详情参看 STOMP 规范 。
MQTT 中的心跳（长连接）
MQTT 3.1.1 中支持心跳检测，它使用了一个不同的名称“长连接” 。RabbitMQ MQTT 插件完整支持这个特性。
长连接在 MQTT 中是可选的。为了开启它，在连接的时候需要设置长连接的 keepalive 时间间隔。有关示例，请查看你的 MQTT 客户端文档。
心跳和长连接
TCP 包含一种目的类似心跳检测的机制（长连接），在信息传递协议和 net tick timeout。因为默认设置的不足，TCP 长连接并不适合甚至适得其反在消息传递协议中。然而，通过适当的调整，在应用程序无法启动心跳检测或使用合理 timeout 值时。它可以作为额外的防御机制。详情请参考网络说明。
心跳和 TCP 代理
某些网络工具（HAproxy, AWS ELB）和设备（硬件负载均衡器）可能关闭在一段时间内没有活动的“空闲”连接，大多数时候这是不可取的。
在连接上启动心跳检测后，它会周期的发送网络检测包。因此，它会保护客户端连接不会因为一段时间的空闲，而被代理和负载平衡器关闭连接。
10 到 30 秒的心跳超时时间产生的周期网络流量（大约 5 到 15 秒）能够满足大多数默认设置的代理工具和负载均衡器。
网友评论