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