问题标签 [akka-persistence]

我最近看了几个关于 ES 和 CQRS 模型的视频，也看了一些关于 AKKA 持久性的讨论。我知道它们是关于什么的，但我在编写将执行的实际代码时遇到问题。

不过我有几个问题。我应该如何使视图和事件堆栈通信？是否会在视图和具有相同持久性 ID 的持久性参与者之间传递事件？根据模型，持久性参与者和视图负责什么？

编辑：我应该把我的业务逻辑放在哪里？根据模型，我应该在写入中执行此操作，但是如果我需要在读取中检查某些内容以验证 cmd 怎么办？

我正在使用 akka-persistence 的 PersistenceQuery 将初始状态加载到管理内容的演员。我希望它在启动时只重播一次，但它会不断将它们发送到日志中。

这是我为实现它而编写的程序。

在我的应用程序中，我有一个发送电子邮件以响应各种用户事件的服务。一直存在一个问题，即由于某种原因，电子邮件发送将失败，因此我们丢弃该消息并且不尝试重试。此故障模型中包括正在关闭的 JVM。规则是不应该发生重复的电子邮件，并且未能发送电子邮件是非常不受欢迎但可以接受的。基本上我们应该能够重试而不用担心重复。

Akko-Persistence 表面上会出现以解决上述问题，但它似乎旨在存储所有消息，然后重播其中的一部分以进行恢复。

期望的行为是当参与者恢复时重播任何未处理的消息（包括发生故障时正在处理的消息）。此外，如果系统被退回，则发送任何待处理的电子邮件。

是否有我错过的 Akka 文档的某些部分或完成上述操作的简单方法？

作为记录，我们正在为此评估 Akka 2.4.8：http: //doc.akka.io/docs/akka/2.4.8/

给定Event-A, Event-B,在几天之内到达（可能乱序），一旦我知道我拥有集合中的所有事件Event-C，我想触发处理以生成导数。Event-ABC

事件按 userId/sessionId 分组

目前我从一个队列中读取所有事件，写入数据库，并更新元数据，说明哪些事件已被写入。一旦元数据包含基于规则的所有事件，我就会触发聚合处理。由于队列工作人员在处理属于同一组的事件时可能会敲击相同的键，因此这种方法存在一些性能问题，因此我正在寻找替代方案。

我想要的是一个更细粒度的软件定义路由和排队事件，基于他们的 userId/sessionId 进行处理。我认为我正在尝试做的事情有点类似于事件溯源。

我正在研究 Akka 是否可以帮助解决此类问题。对于每个 userId/sessionId 的参与者，它将减少不需要的并发性并在参与者中包含触发逻辑。我担心的是使用这么多 Actor 时可能需要大量内存。

根据文档，从外部触发视图更新应该像这样工作：

view ! Update(await = true|false)

发送和等待似乎不起作用：

视图状态未更新。

询问也不起作用 - 没有答案Update并且Await超时：

IIUC，Update消息的处理由 执行PersistentView#State#stateReceive。它的接收没有记录，我不知道如何验证接收和处理。Update味精没有到达receive我的PersistentView.

起作用的是在 a 中设置一个非常短的刷新间隔.conf：

调试日志显示 Journal 正在更新视图：

... a.p.i.e.InMemoryJournalStorage akka://entityViewSpec/user/JournalStorage - received handled message GetJournalEntriesExceptDeleted(ea-ZleUNl1a3N,1,1,9223372036854775807) from Actor[akka://entityViewSpec/temp/$o]

Update发送和等待时我没有看到此日志条目

短暂睡眠后，视图按预期更新。

那么如何在不一直运行自动更新的情况下从外部触发视图更新呢？

阿卡 2.4.8

谢谢

编辑

我的错误很简单 - 没有给初始消息足够的时间来持久化 -Update在商店还没有相关事件的时候收到了电话。自动更新设置在更新前等待 100 毫秒。在具有 in-mem 持久性的本地计算机上，我需要等待大约 50 毫秒，然后再发送Update. 然后给系统一些时间来获取和应用事件：

不工作：

在职的：

我有一个像 /user/{supervisors}/{children} 这样的层次结构。每个主管可以有成千上万的 {supervisors} 和同样多的 {children}。两者都有复杂的状态和许多不同的消息，每个都需要能够处理。

我正在考虑让 {supervisors} 和 {children} 成为有状态的。这最终导致数百万有状态的参与者。

akka可以处理吗？我将使用集群和持久性（当然是必需的）来尝试将数百万演员的负载分散到服务器上（我假设使用循环法进行集群会平均分散我的所有演员）。

我刚开始考虑有状态的开发，并想确保我不会尝试一些不可能的事情。

我们正在使用 AtLeastOnceDelivery 持久演员。我们收到大量未经确认的消息，如果这个数字太大，这会导致 OutOfMemoryError。

有没有办法我们可以配置 AtLeastOnceDelivery 演员将未确认的消息保存在磁盘上，而不是将它们全部保存在内存中，直到它们被确认？

或者更好的是有没有绕过这个限制的 AtLeastOnceDelivery 的替代品？

PersistentView已在 akka 2.4 中弃用。文档建议PersistenceQuery改用。然而PersistenceQuery，似乎仅限于事件日志，没有查询快照存储的能力。

从大量事件中恢复状态需要一些时间，因此使用快照的能力对我来说很重要。

这里的弃用是不是有点超前了？我应该继续工作PersistentView还是我错过了什么？如何使用仅使用快照PersistenceQuery？

谢谢

阿卡提供

1. 具有至少一次消息传递的持久 Actor (链接)
2. 一个持久的 FSM (链接)

我可以将两者混合吗？我希望能够维护一个持久的状态机，但也有阶段更改触发事件，这些事件向其他参与者发送消息，并保证至少一次消息传递

在 CQRS 中，验证需要 DB 调用的命令的最佳方法是什么？例如，我有Order一个正在验证命令的聚合，CommitOrder除非有足够的库存，否则我不想接受这个命令。在这种情况下，命令处理程序如何检查我是否有订单商品的库存？我可以从写入端查询读取端吗？

注意：我使用 akka 来实现