Tomcat 中的高可用性单例处理器

Question

我有一个针对 RDBMS 的作业处理分析服务，由于需要复杂的缓存和缓存更新逻辑，因此它需要是高可用性集群中的单例。作业以 JMS 消息的形式出现（通过 ActiveMQ）。它是托管在带有 Web 前端的 HA Tomcat 集群中的应用程序的一部分。

问题是，如果正在运行的节点发生故障，服务本身需要能够在几秒钟内恢复。故障可能意味着系统关闭或 CPU 速度变慢 - 即如果节点在 CPU 延迟后恢复，但处理已移交，则无法继续。

根据经验，这里最合适的解决方案是什么：

• 在每个作业开始之前基于数据库的锁和锁检查（我无法在这里轻松提出防弹解决方案 - 有什么建议吗？）
• 某种Paxos算法？您是否知道任何用于此目的的苗条框架，因为算法本身需要时间才能正确处理，然后进行 QA？
• 还有什么？

我不介意故障恢复是否缓慢，但我希望尽量减少每个作业的开销。

一些额外的背景：工作不涉及从数据库中读取数据，使用各种算法对其进行按摩（有点类似于寻找最短路线）并为不同的参与者提供最佳解决方案以继续前进。 Actor 与现实世界交互并返回一些反馈，基于这些后续步骤由同一个作业处理器优化。

Answer 1

使用 Hazelcast 的解决方案

Tomasz 作品提出的 Hazelcast 锁定方法。您需要read documentation carefully，使用时间租用锁并确保监控您的单身人士以更新租约。要记住的一件事是，Hazelcast 是为在大型集群中工作而编写的——因此它的启动时间相对较慢，即使对于两个节点也只有 1 到 5 秒。但在那之后，操作非常高效，获得锁需要几毫秒。通常这一切都无关紧要，但故障/恢复周期需要时间，应视为例外情况。

这个解决方案是防弹的。如果集群被拆分（节点之间的网络中断）但每个节点都处于活动状态并且可以访问数据库，则无法确定地知道如何进行。最终，您需要在这里考虑一个应急计划。在现实生活中，这种情况对于典型的故障转移 HA 设置来说是非常不可能的。

归根结底，在采用分布式锁定解决方案之前，请认真考虑使您的进程不那么单一。并行运行某些事情可能仍然很困难，但确保缓存不会过时或找到其他方法来防止数据库损坏可能并不难。在我的例子中，有一个数据库事务计数器像乐观锁一样工作。代码在做出所有决定之前读取它并更新它在存储结果的事务中的数据库和缓存中的位置。如果出现差异，缓存将被清除并重复操作。它使两个节点并行工作变得非常慢，但它可以防止数据损坏。通过使用事务计数器存储额外的数据，您可能能够优化缓存刷新策略并慢慢转向并行处理。

结论。

这就是我下次处理此类请求的方式。

1. 尝试让你的单例在不同节点上并行工作
2. 再试一次，也许有办法安排它们
3. 检查是否可以使用 HASingleton 或类似技术 避免样板
4. 实施上述 Hazelcast 解决方案

在这里发布代码是没有意义的，因为最耗时的部分是测试和验证所有故障场景和应急计划。几乎没有样板，代码本身总是特定于解决方案的。有可能在几天内提出涵盖所有基础的运行良好的 PoC。