心跳协议/算法或最佳实践

最近我为我编写的一个软件添加了一些负载均衡功能.它是一个联网的应用程序,它根据来自SQL数据库的输入执行一些数据处理.由于压缩可能非常密集,我已经添加了在不同服务器上运行此应用程序的多个实例以分割负载的功能,但现在负载平衡是一种手动操作.用户必须指定哪些实例占用输入域的哪个部分.

我想把它提升到一个新的水平,并对实例进行编程,以自动协商输入数据的潜水,并识别其中一个"消失"(已经崩溃或已经断电),以便其余的实例可以采取在失败的实例的工作量上.

为了实现这一点,我正在考虑在实例之间使用简单的心跳协议来确定谁在线以及谁不在线,虽然这不是非常复杂但我想知道是否有任何已建立的心跳网络协议(基于UDP,TCP或两者兼而有之).

显然,在集群,故障转移和高可用性技术的网络世界中,这种情况发生了很多,所以我想最后我想知道是否有任何已建立的协议或算法,我应该知道或实现.

编辑

根据答案,似乎没有完善的心跳协议或没有人知道它们(这意味着它们毕竟不是那么完善)在这种情况下我只是要滚动我自己的.

虽然没有一个答案提供了我特别想要的东西,但我会投票支持Matt Davis的答案,因为它是最接近的,他指出了使用多播的好主意.

谢谢大家的时间〜

分布式交互式仿真(DIS),在IEEE标准1278 下定义,通过UDP广播使用5秒的默认心跳.DIS心跳本质上是实体状态PDU,其完全定义给定实体的状态,包括位置.由于其在模拟社区中的应用,DIS还使用称为航位推算的概念来提供更高频率的心跳,例如,当实际位置超出其预测位置的给定阈值时.

在您的情况下,DIS实体状态PDU将是过度的.我只提到它,以记录心跳根据具体情况而变化的事实.我不知道你所描述的应用程序需要这样的东西,但你永远不知道.

对于心跳,请使用UDP,而不是TCP.心跳本质上是一种无连接的设计,因此UDP(无连接)在这里比TCP(面向连接)更相关.

关于UDP广播要记住的是广播消息仅限于广播域.简而言之,如果您的计算机由第3层设备(例如路由器)分隔,则广播不会起作用,因为路由器不会将广播消息从一个广播域传输到另一个广播域.在这种情况下,我建议使用多播,因为它将跨越广播域,提供生存时间(TTL)值设置得足够高.它也是一种比定向单播更自动化的方法,它要求发送方知道接收方的IP地址以便发送消息.

每隔t使用UDP广播一次心跳；如果您没有收到超过k * t的机器声音，则认为该声音已降低。请注意，使用的总带宽不会浪费资源。您可以使用IP广播地址，也可以保留要为其工作的特定IP的列表。

确保心跳包括“重新启动计数”和“计算机ID”，以便您知道以前的服务器状态不在身边。

如果合适，我建议您使用MapReduce。这样可以节省很多工作。