0

我有一个特定于域的任务管理的有界上下文。一些用户(称为协调者)可以创建任务并将其分配给另一个用户(称为执行者)。Executor 可以在稍后的某个时间完成任务。与此同时,协调者可以将任务重新分配给不同的执行者,后者负责完成该任务。第一个执行者失去了处理任务的能力。

现在情况变得复杂了,因为协调员在 web 应用程序(后端)工作,而执行程序在他们的移动应用程序(客户端)工作。因此,有界上下文有效地分布在许多节点之间。此外,移动应用程序可能会在相当长的一段时间(几天)内完全离线工作。

因此,可能是协调器将任务分配给 executor A,然后 executor 离线。在metime coordinator 决定他不想等待 executor 完成任务A并将任务重新分配给 executor B。但是A由于某些原因,执行者并不知道它并完成了任务。一段时间后执行者A上线,现在我们必须在他的移动应用程序和后端之间一致地同步状态,遵循声称任务只能由其实际执行者完成的业务规则。执行者A告诉后端“嘿,我用那个结果完成了任务”。后端听了 executorA然后他看到当前分配给 executor 的任务B。后端必须回答执行者A:“对不起,目前任务不是你的,请删除手机上的任务,我拒绝你完成任务的结果。”

真实场景要复杂得多:执行者和协调者可以完全独立地完成多种动作,任务。然后在稍后的某个时间,他们应该按照业务规则正确同步状态。

您将如何在假设冲突解决(拒绝、补偿等)的分布式有界上下文中实现此类同步?

4

2 回答 2

1

您将如何在假设冲突解决(拒绝、补偿等)的分布式有界上下文中实现此类同步?

“数据输入”系统最重要的起点是模型不是记录簿,外部世界才是。来自偶尔连接的系统的消息会告诉您这些设备上发生了什么;计算含义是模型的工作。

现实世界并不总是遵循幸福的道路。

抱歉,目前该任务不属于您。请删除您手机上的任务。我拒绝你完成任务的结果。

这仍然可能是您模型的有效响应。我不会说“拒绝你的结果”;我们并不否认执行者提供的结果——我们正在将该信息与我们收集的其他数据合并,并描述有限状态机的当前状态。

换句话说,我们在模型中添加了更多的路径和更多的状态,而不是坚持现实世界只遵循快乐的路径。

于 2019-06-30T11:03:25.027 回答
0

我建议研究Cadence Workflow来实现您的应用程序。当您的代码状态(包括线程和局部变量)即使在存在进程故障的情况下也能长时间持久时,它本质上会暴露持久内存模型。

请参阅有关Cadence 编程模型的演示文稿。

于 2019-07-01T19:37:26.890 回答