我们有一个服务器，它充当 TCP 客户端，接收一些数据，以某种方式处理数据，并向客户端提供处理后的数据，充当 TCP 服务器。它还将这些数据存储在磁盘上，并可以通过文件而不是实时流提供这些数据。
问题是这项服务必须全天候可用，不能中断。目前，它通过两台服务器来实现，其中一台充当热备份 - 客户端与两台服务器保持连接，如果主服务器出现问题，它们只需切换到备份服务器即可。虽然这种解决方案已经运行了大约 15 年，但它有点不方便，并且给客户端带来了很多故障转移逻辑。
最近人们开始谈论使用集群来确保此服务的可用性，但无论我如何努力搜索，我都找不到任何允许透明 TCP 连接故障转移的集群解决方案，这样就没有人会注意到服务器发生了什么。有一些研究论文，但我找不到任何可行的实现。我认为它应该这样工作：
两个服务器都通过 TCP 接收数据。理想情况下，它应该看起来像是与“外部”世界的单一连接，以节省带宽，更重要的是，确保两个服务器都接收相同的数据流。
当客户端连接到集群 IP 时，它会在单个连接中接收处理后的数据，但两个服务器都应该看到此连接并提供数据，只是只有一个流实际上到达客户端，备份流转到 /dev/null，可以这么说。
当服务器发生故障（一段时间内没有传输任何数据，例如 5 秒）时，客户端应继续在同一连接内接收同一流。它需要非常快地发生，因此整体流式传输延迟不会超过大约 10 秒。
可靠性是这里最重要的事情。其次是快速故障转移。开源 Linux 解决方案是首选，但如果存在商业和/或非 Linux 近乎完美的解决方案，我也想了解它们。施加大量限制或需要修改服务器应用程序软件的解决方案也是完全可以接受的。
答案1
您应该查看 HAProxy。HAProxy 通常以 HTTP 模式运行，但它也可以处理原始 TCP 连接。它支持服务器之间的负载平衡，并且可以使用 Heartbeat 来检测实例是否已关闭。
如果您的设置需要完全透明（服务器获取源 IP 与 HAProxy 服务器的源 IP），您可能必须为 TProxy 修补 Linux 内核或者找到在内核或模块中支持 TProxy 的 Linux 发行版。
这是最好的开源解决方案。如果您需要更全面的解决方案，则必须考虑商业产品，例如 Citrix Netscaler for F5 的 BigIP。
答案2
你可以获得这方面的博士学位——这是一个极其复杂的问题。或者，你可以采取简单的方法，修复协议，这样它就不会那么容易出现连接失败的情况。SMTP 是一个不错的模型，可以避免大多数形式的故障导致的数据丢失。