可用性问题

Question

架构： 一堆客户端将消息发送到VIP后面的服务器。显然，这台服务器存在可用性风险。

客户端监视资源，服务器负责根据大多数客户端向其报告的状态采取行动，因此只需要1个服务器/领导者。

我正在考虑在VIP上添加另一台服务器作为备份，只有在第一台服务器出现故障时才会启用该服务器。但是，当备份出现时，它将无法处理任何信息，并且会浪费时间等待客户端报告并等待所需的阈值等。

问题： 只有一个接收客户端流量，让两台服务器共享客户端状态信息的最佳和最简单的方法是什么？

解决方法1： 我想过让服务器将客户端状态信息转发给备份服务器，如果备份服务器出现故障，可以从那里接收它。

还有其他办法吗？我想到了一个公共/共享位置来存储状态信息，其中两个服务器都可以从中读取客户端状态信息。但这并不适用，因为共享空间也是单点故障。

Answer 1

一种选择是使用预写日志。从本质上讲，您对状态所做的任何修改都会被发送到备份服务器，备份服务器会在其自己的状态副本上重放更改。只要它能跟上流式日志，备份就始终是最新的。

这是大多数数据库通常使用的方法;如果你使用一个作为你的后端，你可以通过很少的工作得到支持。

小心计划从通信故障中恢复 - 将日志保存到磁盘并重新发送丢失的部分，或者发送状态的快照，以及自重新连接快照以来的所有日志条目。

Answer 2

有各种分布式缓存产品可以做你在这里讨论的事情。有些是随App Server提供的，例如WebSphere的dynacache和Object Grid。事实上，ObjectGrid可以在JSE中使用，不需要App Server。

这些分布式缓存产品使用各种推送和拉取模型以及pub-sub消息传递来实现实例之间的一致性。为IBM工作我是ObjectGrid的粉丝，但是更加公正，我很喜欢不重新发明轮子。我的看法是，这些东西可能变得非常复杂，因此找到现成的东西可能会节省大量工作 - 这里有各种Open Source solutions的链接。

Answer 3

这在很大程度上取决于您的解决方案需要的可用性（多少9个）。有一系列的解决方案。

可以在Memcache周围制作一个轻量级的：极快的分布状态设施。例如，它广泛用于Google AppEngine。