Akka 持久性演员的用例是什么？

Question

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

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

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

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

谁能给我一些例子？

Answer 1

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

假设您有一个任务管理系统，例如吉拉或类似的。假设您有以下演员布局：

• 项目 1
  • 票 1
  • 票2
• 项目 3
  • 票 3

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

• 上下放置actor会恢复其状态-因此不再需要复杂的查询和映射到actor代码。此外，如果您的应用出现故障，重新启动它实际上会加载包含所有历史记录的数据（如下）
• Actor 模型/Akka 监督会为您提供额外的奖励 - 如果您的 Actor 已经死亡（即，在尝试从外部集成获取数据时任务死亡），重新启动它会带回所有历史记录。
• 跟踪历史记录已经存在（您可以对数据进行建模，以便事件日志实际上包含所有更改数据，如用户和时间戳，以及旧值/新值）。这实际上适用于无数业务领域 - 例如，交易处理，其中每笔交易都必须存储自己的历史记录。
• 另一部分是查询 - 如果您的系统允许最终一致的设计，您可以将数据分散到项目中的所有工单中，无论您想要多么复杂的查询并等待响应。

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