我有一个针对 RDBMS 的作业处理分析服务，由于需要复杂的缓存和缓存更新逻辑，因此需要在高可用性集群中成为单例。作业以 JMS 消息的形式出现（通过 ActiveMQ）。它是托管在具有 Web 前端的 HA Tomcat 集群中的应用程序的一部分。
问题是，如果正在运行的节点发生故障，服务本身需要能够在几秒钟内恢复。故障可能意味着系统关闭或只是 CPU 速度变慢 - 即如果节点在 CPU 延迟后恢复，但处理已移交，则无法继续。
根据经验，这里最合适的解决方案是什么：
我不介意故障恢复是否缓慢，但我想尽量减少每个作业的开销。
一些额外的背景：工作只涉及从数据库中读取数据，使用各种算法对其进行按摩（有点类似于寻找最短路线）并为不同的参与者提供最佳解决方案以继续前进。Actor 与现实世界交互并返回一些反馈，基于这些后续步骤由同一个作业处理器优化。
Tomasz 作品提出的 Hazelcast 锁定方法。您需要仔细阅读文档，使用租用时间的锁并确保监控您的单身人士以更新租约。要记住的一件事是，Hazelcast 是为在大型集群中工作而编写的——因此它的启动时间相对较慢，即使对于两个节点也只有 1 到 5 秒。但在那之后，操作非常高效，获得锁需要几毫秒。通常这一切都无关紧要，但故障/恢复周期需要时间，应视为例外情况。
这种解决方案是防弹的。如果集群被拆分（节点之间的网络中断）但每个节点都处于活动状态并且可以访问数据库，则无法确定地知道如何进行。最终，您需要在这里考虑一个应急计划。在现实生活中，这种情况对于典型的故障转移 HA 设置来说是非常不可能的。
归根结底，在采用分布式锁定解决方案之前，请认真考虑使您的进程不那么单一。并行运行某些事情可能仍然很困难，但确保缓存不会过时或找到其他方法来防止数据库损坏可能并不难。在我的例子中，有一个数据库事务计数器像乐观锁一样工作。代码在做出所有决定之前读取它并更新它在存储结果的事务中的数据库和缓存中的位置。如果出现差异，缓存将被清除并重复操作。它使两个节点并行工作变得非常慢，但它可以防止数据损坏。通过使用事务计数器存储额外的数据，您可能能够优化缓存刷新策略并慢慢转向并行处理。
这就是我下次处理此类请求的方式。
在这里发布代码是没有意义的，因为最耗时的部分是测试和验证所有故障场景和应急计划。几乎没有样板，代码本身总是特定于解决方案的。有可能在几天内提出涵盖所有基础的运行良好的 PoC。