长期 运行 任务的弹性模式
Resilience pattern for a long run task
我的应用是托管在一个容器中的，在真实环境中，部署了3个容器。我说，他们是A、B、C。
应用程序需要执行较长的 运行 任务。所以，这一次，A 开始了一个很长的 运行 任务。而且，如果 A 出现故障，我希望 B 或 C 恢复该任务。我目前的解决方案是，当A启动任务时，A将时间戳、任务状态和执行标志记录写入DB。我有一个超时设置，例如 2 小时。 B和C不断查询数据库，查找状态不是finished且currentTime - the written timestamp超过2小时的任务。然后他们开始恢复任务。
解决方案有问题。比如DB中的task1满足查询状态，B和C都知道task1需要恢复。怎么只让B或者C去接任务呢？
一个简单的解决方案可能是实施锁定机制。例如。乐观锁定方法可能如下所示：B 和 C 都尝试执行任务 1。他们必须向数据库写入一个锁，声明他们是当前所有者。 A是以前的主人。 B 以 B 作为当前所有者写入一条记录。 C，通过写入时检查记录是否仍然包含A，因为当前所有者可以看到他们的请求已过时，C将放弃。
我的应用是托管在一个容器中的，在真实环境中，部署了3个容器。我说，他们是A、B、C。
应用程序需要执行较长的 运行 任务。所以，这一次，A 开始了一个很长的 运行 任务。而且，如果 A 出现故障，我希望 B 或 C 恢复该任务。我目前的解决方案是，当A启动任务时，A将时间戳、任务状态和执行标志记录写入DB。我有一个超时设置，例如 2 小时。 B和C不断查询数据库，查找状态不是finished且currentTime - the written timestamp超过2小时的任务。然后他们开始恢复任务。
解决方案有问题。比如DB中的task1满足查询状态，B和C都知道task1需要恢复。怎么只让B或者C去接任务呢？
一个简单的解决方案可能是实施锁定机制。例如。乐观锁定方法可能如下所示：B 和 C 都尝试执行任务 1。他们必须向数据库写入一个锁，声明他们是当前所有者。 A是以前的主人。 B 以 B 作为当前所有者写入一条记录。 C，通过写入时检查记录是否仍然包含A，因为当前所有者可以看到他们的请求已过时，C将放弃。