设想：
我正在为网络节点实现故障转移，所以我的想法是让主节点监听播送ip 地址和端口。如果主节点发生故障，另一个故障转移节点将开始侦听此广播地址（和端口）并接管。
问题：
我担心的是，我将只对单个节点（主节点）使用广播 IP 地址。故障转移节点仅在主节点发生故障时绑定，换句话说，几乎从不绑定。
从网络/流量开销的角度来看，与单身的节点是否通过广播地址或网络以某种方式足够智能地知道没有其他人在监听该广播地址，并且在开销方面将其视为单播？
我担心的是，即使我实际上只是在与单个节点（主节点）通信，我的网络也会被来自此广播地址的数据包淹没。但我不能使用单播，因为故障转移节点必须能够快速透明地接收主流，以防发生故障。
答案1
听起来你正在尝试以自己的方式重新发明 NIC 组合/集群。大多数主动/被动集群将共享虚拟 IP 和 MAC 地址，当一个单元发生故障时，辅助单元将接管共享的 MAC 地址。使用广播 IP 与集群通信是不正统的，几乎肯定会在整个 LAN 中产生不必要的流量。
答案2
网络通常不可能提前预测或立即意识到节点的故障。
因此，您必须：
- 接受检测故障并转移到故障转移节点总是需要一点时间
- 抢先将流量发送到备份节点，从而降低网络效率
在网络层实现可靠的消息传递既困难又昂贵。这就是我们使用哑分组交换网络并在传输层实现可靠性的原因。在这种情况下，您使用浮动 IP（可能还有 MAC）地址，并等待（网关 ARP 缓存/交换机转发表）更新。
但如果这对你来说至关重要，以至于不能错过任何一个数据包，你就必须付出一些效率代价。如果你使用多播（非广播）地址，并且您的冗余路径通过能够IGMP 侦听，那么它们应该足够智能，至少不会淹没整个 LAN。您仍然需要一种方法让备份节点能够可靠地检测到主节点的故障。
如果你使用流，而不是在多播 UDP 上使用自己的临时可靠协议，你可能需要研究连续传输协议因为它可以处理多宿主，并且可以有利地替代 udp 或 tcp。
答案3
是的，广播有开销。连接到交换机的节点越多，开销就越大。因此，只有当您真的想到达所有节点和/或尝试发现已移动到其他地方的节点时，才应发送广播。广播一次，等待来自节点的回复，无论它在哪里，发现它的新地址，然后从现在开始单播。很美，不是吗？:)
答案4
是否会导致网络泛滥完全取决于广播的频率和大小、广播到的子网的大小、网络拓扑以及设备的功能。
不知道没有人可以肯定地回答你的问题。
但是，DHCP 是广播流量，在大型网络中可能会非常繁琐。许多网络不会采取任何特殊措施来管理此 DHCP 流量 - 影响并不令人担忧。估计您的广播是否会比网络上现有的 DHCP 广播流量多得多 - 如果是，那么您可能需要担心并实施不同的解决方案来解决您遇到的任何问题。如果不是，那么很有可能您可以继续应对下一个挑战。
我很好奇您具体想设置故障转移的目的是什么。正如其他回复者所建议的，有很多冗余选项可供您使用，您无需担心这个问题，还可以借鉴其他人的经验。