Web services 有状态服务器的故障切换策略

在我们的项目中，我们有一个有状态的服务器。服务器运行规则引擎（Drools）并使用rest服务公开功能。这是一个监控系统，正常运行时间达到或低于100%是非常关键的。因此，我们还需要关闭服务器以进行维护的策略，以及能够在一台服务器脱机时继续监视代理的策略

---

第一种可能是在drools服务器前面放置一个消息队列或服务总线，以保留尚未处理的消息，并具有将服务器状态备份到数据库或其他存储的机制。这样就可以关闭服务器几分钟以部署新版本。但问题是，当一台服务器意外脱机时该怎么办。是否有针对有状态服务器的故障切换策略，您有何经验？欢迎提供建议。

我想不出什么“正确”的方法。这取决于以下因素：

随时间窗口变化的敏感性

您的应用程序需要以多快的速度恢复

如果错过了事件，将产生影响

如果正在监视的事件未达到秒级，则会产生影响

应用程序如何将事件发回外部世界

启用故障转移的一些想法：

从头开始。在花时间开发任何其他东西之前，先检查一下这一问题最严重的影响

从数据库加载事实列表（可能是今天的事务）。可能按顺序重播。可能是在使用伪时钟时。我知道这被用于金融部门的一些定价应用程序，但同时我也知道，由于需要重播的事件数量太多，其中一些系统可能需要很长时间才能赶上

定期持久化有状态会话。要根据DR应用程序允许落后的距离以及会话持续时间确定的间隔。这样，DR应用程序就可以从数据库中检索相同的会话。但是，根据持续时间间隔，接收到的事件将有一个间隔。当然，如果失败的原因是会话的损坏，那么这就不能很好地工作

将中间件配置为将事件转发到2个队列，并将主应用程序和灾难恢复应用程序订阅到这些队列。这样，两个监视器应该同步，并且能够根据最后1分钟的活动做出决定。请注意，如果一段时间内一个分支被取出，那么它将需要赶上，并且您的中间件需要在队列上存储多个小时（不管中断时间有多长）的事件的容量。此外，您的规则需要在排队时去掉事件本身的时间戳，而不是当前时间。否则，当停机后恢复一段时，它很可能会根据时间窗口中的事件发出警报

重放事件时要考虑的另外一点是，在完成重放之前，您可能不希望任何警报被提升到外部。例如，您可能不希望发送50封提醒电子邮件，告诉您ApplicationX已停止运行、停止运行、停止运行、停止运行、停止运行

我假设监控应用程序可能会以某种形式向外部世界发送警报。如果您有如4所示的热配置，则还需要控制警报。我很想通过配置每个队列将警报推送到自己的队列来解决这个问题。然后，中间件可以将警报从辅助监视器转发到死信队列。故障转移将是重新配置中间件，以便主要警报进入死信队列，次要警报进入警报通道。此机制还可用于丢弃重播恢复期间引发的事件

考虑到重播事件可能带来的复杂性和潜在的混乱，对于监控应用程序，我可能更喜欢从头开始，或者使用持久化会话。然而，这很可能取决于您监视的内容