0

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

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

4

1 回答 1

1

没有我能想到的“正确”方式。它取决于以下内容：

  1. 对时间窗口变化的敏感性。
  2. 您的应用程序需要以多快的速度恢复。
  3. 如果错过事件的影响。
  4. 如果它正在监视的事件没有达到第二个影响。
  5. 应用程序如何将事件反馈给外部世界。

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

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

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

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

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

于 2014-03-06T10:01:13.587 回答