最近，我在自己编写的一个软件中添加了一些负载平衡功能。它是一个网络应用程序，根据来自 SQL 数据库的输入执行一些数据处理。由于处理可能非常密集，我添加了让该应用程序的多个实例在不同服务器上运行以分割负载的功能，但现在负载平衡是手动操作。用户必须指定哪些实例占用输入域的哪个部分。
我想将其提升到一个新的水平，并对实例进行编程以自动协商输入数据的潜水，并识别其中一个是否“消失”(已崩溃或已断电)，以便剩余的实例可以使用在失败实例的工作负载上。
为了实现这一点，我正在考虑在实例之间使用简单的心跳协议(protocol)来确定谁在线，谁不在线，虽然这不是很复杂，但我想知道是否有任何已建立的心跳网络协议(protocol)(基于UDP、TCP 或两者)。
显然，在集群、故障转移和高可用性技术的网络世界中，这种情况经常发生，所以我想最后我想知道是否有任何我应该了解或实现的既定协议(protocol)或算法。
编辑
根据答案，似乎要么没有完善的心跳协议(protocol)，要么没有人知道它们(这意味着它们毕竟还没有那么完善)在这种情况下，我只会滚动我自己的。
虽然没有一个答案提供了我正在寻找的具体内容，但我将投票给 Matt Davis's answer因为它是最接近的，他指出了使用多播的好主意。
谢谢大家的时间~
最佳答案
Distribued Interactive Simulation (DIS)，在 IEEE 下定义标准 1278，通过 UDP 广播使用 5 秒的默认心跳。 DIS 心跳本质上是一个实体状态 PDU，它完全定义了给定实体的状态，包括位置。由于其在模拟社区中的应用，DIS 还使用称为航位推算的概念来提供更高频率的心跳，例如，当实际位置超出其预测位置的给定阈值时。
在您的情况下，DIS Entity State PDU 将是矫枉过正。我只提到它是为了说明心跳的频率可能会因情况而异。我不知道您描述的应用程序是否需要这样的东西，但您永远不知道。
对于心跳，使用 UDP，而不是 TCP。心跳本质上是一种无连接的设计，因此在这里 UDP(无连接)比 TCP(面向连接)更相关。
关于 UDP 广播要记住的是，广播消息仅限于 broadcast domain .简而言之，如果您的计算机被第 3 层设备(例如路由器)隔开，那么广播将不起作用，因为路由器不会将广播消息从一个广播域传输到另一个广播域。在这种情况下，我建议使用多播，因为它将跨越广播域，前提是生存时间 (TTL) 值设置得足够高。这也是一种比定向单播更自动化的方法，定向单播需要发送者知道接收者的 IP 地址才能发送消息。
关于sockets - 心跳协议(protocol)/算法或最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/1442189/