有状态服务器的故障转移策略

Question

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

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

Answer 1

我无法想到'正确'的方式。它取决于以下内容：

1. 对时间窗口变化的敏感度。
2. 您的应用程序需要多快恢复。
如果错过了活动，
3. 会受到影响。
4. 影响，如果它正在监控的事件不是第二个。
5. 应用程序如何将事件发回外部世界。

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

1. 从干净的石板开始。在花时间开发其他任何东西之前，先检查一下这种影响最严重的影响。
2. 从数据库加载事实列表（可能是今天的事务）。可能有序重播。可能在使用伪时钟时。我知道这被用于金融领域的一些定价应用程序，虽然与此同时，我也意识到由于需要的事件数量，其中一些系统可能需要很长时间才能赶上被重播。
3. 定期保持有状态会话。基于允许DR应用程序落后多远以及持续会话所需的时间来确定的间隔。这样，DR应用程序可以从数据库中检索相同的会话。但是，根据持续时间间隔，收到的事件将存在差距。当然，如果失败的原因是会话损坏，那么这不会很好。
4. 配置中间件以将事件转发到2个队列，并将主应用程序和DR应用程序订阅到这些队列。这样，两个监视器应该同步并且能够根据最近1分钟的活动做出决定。请注意，如果一条腿被取出一段时间，那么它将需要赶上，并且您的中间件需要能够在队列中存储多个小时的事件（无论多长时间可能是中断）。此外，您的规则需要在排队时关闭事件本身的时间戳，而不是当前时间。否则，在中断后将一条腿带回来时，它很可能会根据时间窗口中的事件发出警报。

重播事件时需要考虑的另一点是，在完成重播之前，您可能不希望将任何警报提升到外部世界。例如，您可能不希望发送50封警报电子邮件，表示ApplicationX已关闭，向上，向下，向上，向下，向上，......

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

考虑到重放事件可能带来的复杂性和潜在的混乱，对于监控应用程序，我可能更喜欢从干净的平板开始，或者使用持久化会话。但是，这很可能取决于您正在监控的内容。