节点脚本 – 从一台服务器故障切换到另一台服务器

我有一个nodejs脚本 – 在server1上称它为“process1”,同样的脚本在server2上运行 – “process2”(只是flag = false)。

Process1将执行预处理动作,并在开始时处于“运行”状态。 process2将会运行,但处于“block”状态,并在其中设置了标志。

我想要实现的是为此过程实现故障转移/回退。 如果process1下降,process2上的标志将会改变,而process2将接pipeprocess1中的所有任务(当process1回来时,反之亦然 – fallback)。

什么是最好的方法来做到这一点? 那些TCP连接?

在这里输入图像描述


注:即使它没有太多的相关性,但我想提一下,这些进程将在内部工作,与第三台服务器build立TCP连接,并parsing我们从该服务器获得的数据。 两个进程都将在两台服务器上运行,但是当时只有一个进程可以提供服务 – 运行时标志为true(而不是两者都有)


更新:根据以下讨论和内部研究/testing和解决scheme的监测, 使用反向代理将为您节省大量的时间 。 仅基于2台服务器的编程故障转移将覆盖70%与两台机器上使用的内部进程相关的情况 – 但是由于存在问题,您将无法检测到其他30%的问题networking(特别是如果你有大量的数据接收器的stream量)。

这是一个基础设施问题,而不是一个节点,同样的情况可以应用于几乎所有的服务器。

你基本上需要的是一些监视Server 1服务,并确定它是“健康的”还是“活着的”,如果是的话继续引导stream量到它。 如果服务确定服务器不再处于稳定状态(例如,响应时间过长,返回错误),则将任何传入的通信redirect到Server 2 。 当Server 1恢复到正常运行状态时,它会将stream量redirect到它。

在大多数情况下,这种情况下的“服务”是一个像Nginx或CloudFlare这样的反向代理 。 在你的情况下,这个服务器将充当Data Reciever和你的networking( Server 1 / Server 2 )之间的缓冲区,并将传入的通信路由到相关的服务器。

这看起来像一个反向代理的经典用例。 使用经过良好testing的服务器(如nginx)应该提供足够的可靠性,代理服务器不会失败(硬件故障除外),您可以将任何群集大小的前面。 如果适用并正确configuration,您甚至可以获得负载均衡的好处。

另外,也可以倾向于使用负载均衡解决scheme,您可以让前端服务器将请求推入队列(例如ZMQ),并从队列中推送到应用服务器或让您的应用程序服务器来自队列的任务独立。

在这两种解决scheme中,如果要求不将“2个”同步结果“推送”到数据接收器,则可以使用所有应用服务器推入的出站队列。

Interesting Posts