问题是该服务必须以24×7模式提供,不允许中断.现在它通过两个服务器完成,一个作为热备份 – 客户端维护与两个服务器的连接,如果主服务器发生某些事情,他们只需切换到备份.虽然这个解决方案已经运行了大约15年,但它有点不方便,并且在客户端上放置了很多故障转移逻辑.

最近人们开始谈论使用群集来确保此服务的可用性,但无论我搜索多么困难,我都找不到任何允许透明TCP连接故障转移的群集解决方案,因此没有人会注意到服务器发生了什么事情.有一些研究论文,但我找不到任何有效的实施方案.以下是我认为它应该如何工作：

>两台服务器都通过TCP接收数据.理想情况下,它应该看起来像是与“外部”世界的单一连接,以节省带宽,更重要的是,确保两个服务器都接收相同的数据流.
>当客户端连接到群集IP时,它会在单个连接中接收已处理的数据,但是两个服务器都应该看到此连接并提供数据,只是其中一个流实际到达客户端,备份就是to / dev / null,所以说.
>当服务器发生故障(它在一段时间内没有传输任何数据,比如5秒)时,客户端应继续在同一连接中接收相同的流.它需要发生得非常快,因此整体流延迟不会超过大约10秒.

可靠性是这里最重要的事情.快速故障转移是下一个.开源Linux解决方案是首选,但如果存在商业和/或非Linux近乎完美的解决方案,我也想了解它们.强加许多限制或需要修改服务器应用程序软件的解决方案也是完全可以接受的.