0

我最近开始研究一个系统,我正在使用 Akka.NET。我仍在学习如何从演员模型的角度思考,所以我愿意接受更有经验的人的建议。

我试着先问一个更一般的问题:

如果决策必须基于分布在多个参与者类中的多个参数和复杂的业务规则,如何通过管理实体跟踪子参与者状态以决定与哪个孩子交互。

我将尝试简化我面临的问题:假设我有一个 Actor System,并且有一个 Actor,称为​​ Backlog

Backlog负责创建和监督Jobs(也是 Actor)

作业有一个生命周期,为了简单起见,它们可以是ActiveCompleted。它们被创建为 Active,并在收到特定消息时变为 Completed。完成并不意味着终止。那是后来的,在某个时候(所以没有死亡守望)。作业可以并最终与Resources相关联。一个Job可能与零个、一个或多个Resources相关联。

资源是不受Backlog监督的参与者。资源数量有限。

任何时候只能将一个活动作业与资源相关联。

Resource可能与Job没有关联。Resource可能不知道与Job关联。

资源有时会被传感器检测到。检测器需要知道资源意图IntentionJob可变状态的一部分。

Resource本身没有Intention,只有在与Job关联时才具有Intention ,但在被询问时需要声明Intention,因此需要确保有关联的Job。(因为检测器检测的是资源,而不是作业。)

在我的设计中,Resource需要向Backlog询问Job,如果它在被检测到时没有。

现在,Backlog可能有也可能没有此资源的Job。如果没有,它应该创建一个(假设它知道如何)。为了做到这一点,它需要知道它的哪些作业是活动的,以及这些作业是否已经与请求的资源相关联。

还在我这儿?

那么我应该如何让Backlog找出它是否有Resource R的Job呢?我是否应该向所有 Job 参与者广播一条消息并询问他们是否处于活动状态?如果他们不小心处理R?我如何确保所有作业都确实处理了它,以及我应该等待他们多长时间来处理它(特别是因为 0 毫秒似乎是此类简单任务的唯一可接受的性能)。

或者我应该保留按资源标识符保存作业参与者引用的字典?以及参与此决定的(最后已知的)州?那么我应该如何维护这些字典呢?寻找域事件?或者为Jobs引入更多消息,通过 at-least-once 保证告诉Backlog他们的状态变化?

老实说,我喜欢使用 Actor 模型的思维方式和好处,但是这里需要大量代码来实现类似于传统 OO 中的单行 LINQ 查询的功能,这让我担心其余部分的意愿的团队将处理此代码。

总结

我有一个演员Backlog负责创建和监督Jobs,其他演员代表领域中的一个概念。在某些情况下,它需要根据一些涉及子 Actor 的可变状态的标准来准确选择这些 Job 之一,或者确定当前是否没有可用的 Job。(有多个合适的工作表明存在问题,应该被检测到。)

问题:除了向所有工作广播一些消息、包含标准并等待每个工作应用此标准以自己响应正面或负面答案之外,我是否还有其他选择?

4

1 回答 1

0

尽管您描述了很多,但缺少一些重要的细节,例如积压是在 FIFO 中处理的吗?这对解决方案很重要。

  1. 例如,如果他们这样做,我会使用一些队列,例如 RabbitMQ,当参与者准备好时,它们可以拉出任务,这样积压的参与者甚至不应该关心,它只是将作业分派到适当的队列中。
  2. 如果您不完全关心订单,您可以使用路由器并将请求(命令/消息)发送到 |R| 之一 作业参与者,并使用例如最小队列大小的路由策略。

如果我要回答主要问题,一种方法是配置管理器以接收更新子状态并在内部更新它的命令,这很容易并且不需要管理器参与者中的字典,因为它保证一次执行单个命令。

除非您的问题从根本上缺少某些东西,否则您已经描述了与 LINQ 的关系似乎根本不清楚。

于 2018-01-20T13:53:31.997 回答