集群中的每对节点都通过许多 TCP 连接进行通信，这些 TCP 连接保持打开状态，直到一个节点关闭或由于基础结构故障导致节点之间的通信中断。
通过隐藏通信应用程序中的临时网络中断，TCP 可以在偶尔不可靠的网络上提供可靠的通信。在通知发件人任何问题之前，您的操作系统将多次重发丢失的消息。大多数 Linux 发行版默认将任何丢失的数据包重传 15 次。重新传输以指数方式回退，因此这 15 次重新传输需要 900 秒钟以上的时间才能完成。这意味着使用这种方法，Linux 需要花费几分钟的时间来检测网络分区或故障节点。 Windows 默认仅重传 5 次，相应的超时时间约为 6 秒。
Linux 默认设置允许通过可能遭受很长数据包丢失的网络进行通信，但是对于大多数 Elasticsearch 集群而言，此默认设置对于单个数据中心内的生产网络而言过于昂贵。高可用性集群必须能够快速检测节点故障，以便它们可以通过重新分配丢失的碎片，重新路由搜索以及可能选择一个新的主节点来迅速做出反应。因此，Linux 用户应减少最大 TCP 重传次数。
通过以 root 身份运行以下命令，可以将最大 TCP 重传次数减少到 5 。五次重发对应于大约六秒钟的超时。
sysctl -w net.ipv4.tcp_retries2=5
要永久设置此值，请更新 /etc/sysctl.conf 中的 net.ipv4.tcp_retries2 设置。要在重启后进行验证，请运行 sysctl net.ipv4.tcp_retries2 。
IMPORTANT: 此设置适用于所有 TCP 连接，并且也会影响与集群外部系统的通信可靠性。如果您的集群通过不可靠的网络与外部系统通信，则可能需要为 net.ipv4.tcp_retries2 选择一个更高的值。因此， Elasticsearch 不会自动调整此设置。
Related configuration
Elasticsearch 还实施自己的内部运行状况检查，其超时时间比 Linux 上的默认重传超时时间短得多。由于这些是应用程序级别的运行状况检查，因此其超时必须考虑到应用程序级别的影响，例如垃圾收集暂停。您不应减少与这些应用程序级运行状况检查相关的任何超时。
您还必须确保您的网络基础结构不会干扰节点之间的长期连接，即使这些连接看起来是空闲的也是如此。当设备达到一定寿命时断开连接的设备是 Elasticsearch 集群的常见问题根源，因此不能使用。
详情见官网：www.elastic.co/guide/en/el…
翻译不准请多指教，翻译不易请勿盗用，如使用请标明出处
