可用性问题
体系结构： 一群客户端发送消息到VIP后面的服务器。很明显，这个服务器会带来可用性风险。可用性问题
客户端监视资源，服务器负责根据大多数客户向其报告的状态采取操作，因此仅需要1台服务器/组长。
我正在考虑在VIP上添加另一台服务器作为备份，只有当第一台服务器出现故障时才会打开它。然而，当备份来了那就没有信息处理和将失去的时间等待客户端上报并等待所需的阈值等
问题： 什么是有两台服务器的最好和最简单的方法只有一个接收客户端流量共享客户端状态信息？
解决方法1： 我认为有其服务器转发客户端状态信息的备份服务器，并在出现故障的情况下，当备份服务器上来，就可以把它从那里。
有没有其他方法可以做到这一点？我想在两个服务器都可以读取客户端状态信息时有一个公共/共享位置来存储状态信息。但是，这并不能很好地工作，因为共享空间也是单一故障点。
一种选择是使用预写日志。实质上，对状态进行的任何修改都会发送到备份服务器，备份服务器会在其自己的状态副本上重放更改。只要它能跟上流式传输日志，备份就始终保持最新状态。
这是大多数数据库通常使用的方法;如果你使用一个作为你的后端，你或许可以在很少工作的情况下获得支持。
请小心制定一个计划以从通信故障中恢复 - 将日志保存到磁盘并重新发送缺少的部分，或发送状态快照以及重新连接后自快照以来的所有日志条目。
嗯...我正在寻找一种设计来保持两台服务器同步。我不关心预写日志，因为我们可以在通信失败的情况下重试。 有没有一种设计可以帮助保持两台主机同步？延迟同步不是问题。 – user117736 2009-09-10 21:20:02
write-ahead-log _does_使它们保持同步 - 您只需将日志写入其他服务器即可。由于日志具有所有状态更改，因此通过重播它可以获得与主服务器上的状态相同的状态。 – bdonlan 2009-09-10 22:10:56
有各种各样的分布式缓存产品可以处理您在此讨论的事情。一些与App Server一起提供，例如WebSphere的dynacache和Object Grid。事实上，ObjectGrid可以在JSE中使用，不需要App Server。
那些分布式缓存产品使用各种推 - 拉模型和pub-sub消息传递来实现跨实例的一致性。为IBM工作我是ObjectGrid的粉丝，但更具有吸引力，我很喜欢不重新发明*。我的看法是，这些东西可能会变得非常复杂，因此找到现成的东西可能会节省大量的工作 - 这里有各种Open Source solutions的链接。
如果您定义VIP，它可能会有帮助。 – 2009-12-30 10:42:35