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