演员模型akka是否适合我的应用？

问题描述

一段时间以来，我一直在阅读博客，收听播客和阅读Akka文档，但我仍然不能说我真的很了解actor模型是否适合我要解决的问题。

让我们以构建一个应用程序为例，该应用程序告诉您哪种狗最适合一个人（不是我真正在制造的狗，而是对描述我想制造的东西很有帮助）。 我每秒都会收到很多消息，其中的人希望知道要买哪只狗，而系统应该根据我有关该人的信息来决定应该买哪只狗。

1. 事件： A人想要一条狗

2. 我的订户： 好的，A人想要一只狗，让我们检查一下哪只狗能把它们救出来->请我的应用程序找出答案

3. 应用程序：

• 获取请求
• 从其他系统中收集有关此人的更多数据（他们的住所，空间，时间，运动程度等）
• 要求线程/演员/什么不使用一组规则来检查他们应该得到哪种狗

示例：

• 该人是否居住在这些区域中的任何一个区域（检查是否有适合大型犬的区域的缓存）（大多数检查将在列表中查找事物）
• 此人的房屋比x大还是小？
• 该人是否长时间工作？
• 等

所有这些检查都将结果返回给应用程序，应用程序将收集所有答案，直到一切完成，然后根据该结果决定结果。

现在要记住，始终会有很多消息，我想同时运行这些检查，以便能够尽快答复。该应用程序将在Kubernetes集群中的容器中运行，我希望能够在出现高峰负载或将来消息量增加时扩展该应用程序。

我到目前为止

actor模型似乎适合我的应用程序的第一部分（获取为某人找到合适的狗的请求），因为它具有自己的状态，可以根据从其子actor /线程获得的答复进行管理/任何。

但是：实际执行检查的工人不需要内部状态，因为他们只是在检查有关人员的某些信息是否在列表XYZ中或人员的​​房屋是否大于X。 （所以不是很好地利用演员）

因此：演员模型对我的应用程序是否构成过大杀伤力？我应该代替使用什么？只是期货？如果我使用actor模型，是否应该使用Akka群集？ Akka流可以替代吗？

我很困惑！

解决方法

akka actor非常适合在应用程序中管理状态。在您的用例中，状态可能是来自以下询问的结果：

...来自其他系统的关于此人的数据（他们的住所，空间，时间，运动程度等）

如果您想尽快执行这些请求，那么将这些数据缓存在应用程序内存中并使用actor来存储这些数据听起来很不错。

要执行检查，akka流和图DSL是您的不错选择。

val ask1 = Flow[Req].mapAsync(1) { req =>
  someActorRef ? req
}
val ask2 = ...

val bcast = b.add(Broadcast[Req](N))
val zip = b.add(Zip(...))
bcast.out(0) ~> ask1 ~> zip.in0
bcast.out(1) ~> ask2 ~> zip.in1
...

随时阅读https://doc.akka.io/docs/akka/current/stream/stream-graphs.html，以进一步了解akka流。它可以轻松地与akka演员和akka http集成。

是否是Akka集群是另一个问题，绝对需要更多信息来做出决定，例如用户群的大小。