网络心跳时间（节点间通信心跳）

概述

本指南介绍了 RabbitMQ 节点和 CLI 工具（实际上是 Erlang 节点）用来确定对等节点是否可用的机制，称为“网络心跳”或 kernel.net_ticktime。

集群中的每对节点都通过传输层连接。周期性的心跳消息在所有节点对之间交换，以维护连接并检测断开连接。否则，网络中断可能会在相当长一段时间内未被检测到（取决于传输和操作系统内核设置，例如 TCP）。从根本上讲，这与 心跳 在消息传递协议中试图解决的问题相同，只是对等方不同：RabbitMQ 集群节点和 CLI 工具。

节点和连接的 CLI 工具定期相互发送小数据帧。如果在给定的时间内没有从对等节点收到任何数据，则该对等节点被视为不可用（“宕机”）。

当一个 RabbitMQ 节点确定另一个节点已宕机时，它将记录一条消息，其中包含另一个节点的名称和原因，例如

2018-11-22 10:44:33.654 [info] node rabbit@peer-hostname down: net_tick_timeout

在本例中，net_tick_timeout 事件告诉我们，另一个节点被检测为宕机是因为网络心跳超时。另一个常见原因是 connection_closed，这意味着连接在 TCP 级别被显式关闭。

Erlang 文档 包含有关此子系统的更多详细信息。

心跳频率

心跳消息和故障检测的频率都由 net_ticktime 配置设置控制。通常，每对节点之间每 net_ticktime 秒交换四个心跳。如果在 net_ticktime (± 25% for ) 秒内没有从节点收到任何通信，则该节点被视为宕机，不再是集群的成员。

增加集群中所有节点的 net_ticktime 将使集群更能抵抗短暂的网络中断，但剩余节点检测到崩溃节点的时间也会更长。相反，减少集群中所有节点的 net_ticktime 将减少检测延迟，但会增加检测到虚假 分区 的风险。

应该仔细考虑更改默认 net_ticktime 的影响。集群中的所有节点必须使用相同的 net_ticktime。以下 advanced.config 配置示例演示了将默认 net_ticktime 从 60 秒增加到 120 秒

[
  {kernel, [{net_ticktime,  120}]}
].

对 HTTP API 的影响

HTTP API 通常需要执行集群范围的查询，这会导致 UI 在检测到分区并处理之前显得无响应。降低 net_ticktime 可以帮助提高此类事件期间的响应速度，但任何更改 net_ticktime 的决定都应谨慎行事，如上所述。

Windows 配置

由于 RabbitMQ 作为 Windows 服务启动的方式，您不能使用配置文件来设置 net_ticktime。请参阅 Windows 配置 文档中的 此部分，了解如何在以 Windows 服务形式运行 RabbitMQ 时设置 net_ticktime。