akka - Akka 持久性 Actor 的用例是什么？

Question

我对 Akka 持久性和持久性 Actor 的适用性一团糟，什么时候应该使用持久性 Actor ？

以给定购物应用程序的购物车模块为例，每个用户的购物车 session 是否都是具有各自唯一持久性 ID 的持久性参与者？

在实际应用中的可用性是什么？查询端如何处理持久参与者的状态？当持久性actor在实际应用程序中没有用时？

存储状态或存储消息，是一回事吗？不是吗？有什么区别，什么时候应该使用每个？

有人可以给我一些例子吗？

Answer 1

这将是一个高度自以为是的问题，也是高度自以为是的答案。

想象一下，你有一个任务管理系统，例如吉拉或类似的。假设您有以下 Actor 布局:

项目一

票 1

票2

项目 3

票 3

如果项目和票证实际上是持久性参与者，那么与标准方法(查询等)相比，您有以下好处:

上下放置actor会恢复其状态——因此不再需要复杂的查询和映射到actor代码。此外，如果您的应用程序已关闭，重新启动它实际上会加载包含所有历史记录的数据(如下)

Actor 模型/Akka 监督为您提供了额外的奖励 - 如果您的 Actor 已经死亡(即在尝试从外部集成获取数据时任务死亡)，重新启动它将带回所有历史记录。

跟踪历史记录已经存在(您可以对数据进行建模，以便事件日志实际上包含所有更改数据，例如用户和时间戳，以及旧值/新值)。这实际上适用于数以亿计的业务领域——例如，交易处理，其中每笔交易都必须存储自己的历史记录。

另一部分是查询 - 如果您的系统允许最终一致的设计，您可以将数据分散到项目中的所有工单，无论您想要多么复杂的查询并等待响应。

有用性来自应用程序的设计 - 有些非常适合(即多个独立或松散耦合的实体)，有些则不太合适(即您只想存储最后一组数据并生成它的预定义报告)