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

Question

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

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

Answer 1

我没有想到的“正确”方式。它取决于如下几点：

1. 对时间窗口变化的敏感度。
2. 您的应用程序需要多快才能恢复。
3. 如果事件被错过，会产生影响。
4. 如果它正在监测的事件没有达到第二个，则会受到影响。
5. 应用程序如何将事件引发回外界。

的一些想法实现故障切换：从

洗涮

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

重放事件时需要考虑的另一点是，您可能不希望在完成重播之前向外界提示任何警报。例如，您可能不希望发送50封警报电子邮件来说明ApplicationX处于关闭，上下，上，下，上......

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

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