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

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

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