问题标签 [akka-persistence]

我想使用 akka-persistence 事件溯源功能，以便在我的新项目中实现 CRQS + 事件溯源理念。问题是除了文档（http://doc.akka.io/docs/akka/snapshot/scala/persistence.html）之外，我找不到任何好的示例或指南如何处理它。该文档很好地解释了架构的所有构建块，如处理器、视图、通道，但没有解释如何将它们组合在一起。

所以问题是：我应该如何将写入模型与 akka-persistence 中的读取模型连接起来？我想出了三个选择：

• 直接连接EventsourcedProcessor -> View，View直接从日志中接收所有事件。这似乎是最简单的解决方案，但我想知道我们是否可以使用这种方法在不同的节点上分配处理器和视图。

• EventsourcedProcessor -> 频道 -> 视图/普通 Actor。与第一个选项有什么区别？如果这是正确的解决方案，为什么我们在 akka-persistence 构建块中有视图？我应该使用 Channels 还是 PersistentChannels ？

• EventsourcedProcessor -> 某种事件总线（例如 context.system.eventStream） -> Views/Actors。

最好的方法是什么，为什么？

我正在尝试使用 akkas 持久性模块（2.3.0），不幸的是，当我发送包含枚举的持久性消息时，我得到 java.io.NotSerializableException. 这是我的朴实的例子：

这以

任何人都知道这里发生了什么以及如何解决它？

知道为什么在将 Akka 添加到我的库依赖项并执行test任务后会出现以下错误吗？

当我执行run任务时：

我的相关build.sbt设置

和我的project/plugin.sbt

这是在我添加了带有以下库的 akka-persistence 插件之后开始的：

我安装了 Cassandra，并在执行此操作时在本地运行它。

即使我注释掉这些行中的任何一行并运行sbt clean, sbt update，sbt test我仍然会看到此错误。只有当我将它们全部注释掉时，我才能运行和测试我的应用程序。

我唯一的猜测是持久化库中的Akka版本和Play2不兼容。

听起来对吗？

有没有什么方法可以结合akka 2.3和play 2.2？现在我在运行这样的应用程序时得到 AbstractMethodError 。我需要将它们都放在一个应用程序中，因为 Akka 2.3 带有非常有用的 akka 持久性模块，它非常可靠（与它的前身相反），这种可靠性在我的情况下非常重要。我已经尝试从源代码编译 play 2.2.2 并将 akka 依赖项更改为 2.3，但我仍然遇到相同的错误：

假设我们有一个生成两个事件的写入模型（域）：

• 运营商添加（...）
• BusConnectionCreated（运营商，...）

Carrier 和 BusConnection 类是（部分）单独的聚合。BusConnection 分配给 Carrier 并包含其 CarrierId（单独的聚合仅由 id 引用）。

在正常的命令和事件流期间，写入模型和读取模型都很好，但是当我们想从头开始重建/添加新的读取模型时就会出现问题。

许多人建议（例如 akka-persistence 库）将事件按聚合存储在事件存储中。当非规范化器要求回复事件时，他从每个聚合中获得两个独立的事件流。问题是来自不同聚合的某些事件（如上面的示例）需要按照它们添加到事件存储的相同顺序进行回复。这意味着我们需要某种因果依赖/偏序。

最后是我的问题：

• 我应该重新考虑我的域设计（错误的聚合边界？）还是
• 我只需要强制执行部分排序吗？

如果是后者，那么最有效的方法是什么？

• 全球柜台？似乎没有可扩展性。
• 某种矢量时钟？
• 当它们出现时在反规范化器中检测到这些问题？例如，我们得到了 CarrierId，我们还没有具有此 ID 的 CarrierAdded 事件，所以我们将事件存储起来并首先等待预期的事件
• 在重放模式中处理事件方面引入一些顺序？例如，首先与运营商有关的所有事件，然后是与 BusConnection 相关的事件？

I have created an actor which extends UnTypedProcessor. I intend to use this actor to persist some of it's messages to disk. The actor looks like so,

I have a unit test written for this like so,

When I run this test the onReceive method of the UntypeProcessor does not get invoked. If I extended my class from UntypedActor instead things work just fine. Any ideas why extending UntypedProcessor does not work? Is there some configuration I need to add to get this to work? Is there something that needs to be mocked?

我有多个用例需要根据特定用户操作触发预定义事件。

例如，假设在应用程序中创建时，NewUser它必须异步调用。还有许多其他这种性质的业务案例，其中将基于用例预定义事件。我可以使用 Promises/Futures 对这些事件进行建模，如下所示CreateUserInWorkflowSystemFireEmailToTheUser

所有这些Future调用都必须在某处记录失败，因此可以重试失败的调用等。注意NewUser调用不会等待那些Futures（每个说的事件）完成。

那是使用普通的Futures/PromisesAPI。但是我认为Akka Persistence将是一个合适的选择，并且阻塞调用仍然会遇到Futures. 使用 Akka 持久性，处理失败将很容易，因为它提供了开箱即用等。我知道 Akka 持久性仍处于实验阶段，但这似乎不是一个大问题，因为类型安全通常会在推广之前将这些新框架保持在实验状态进入未来的版本等（宏也是如此）。鉴于这些要求，您认为Futures/PromisesAkka 持久性更适合这里吗？

有几个用例如下。

1) createUserAPI 调用是通过前端进行的。一旦这个调用成功，意味着数据成功保存到db，返回成功到前端。API 合约在前端和后端之间结束。

2）现在后端需要生成并触发CreateUser将用户创建到第三方应用程序中的事件（例如，我们可以说它将 createUser 到外部授权系统中）。这是完全异步的后台类型进程，客户端既不知道也不等待此 API 的成功或失败。CreateUser但是必须记录对此事件的所有调用以及它的失败或成功，以用于审计和补救（在失败的情况下）目的。

第一种方法是我们Future为这些异步事件（应用程序的其余部分大量使用）设计基于异步 API，将Futures传入async事件和结果的成功/失败记录到数据库中。

第二种方法是我们使用 Akka 并为这些事件设置单独的参与者（例如CreateUser，一个示例）。这可能看起来像

}

第三种方法使用Akka Persistence，因此事件的持久化可以通过事件源日志开箱即用地发生。然而，事件成功或失败的第二次持久性将是手动的（为其编写代码）。虽然这第三种方法看起来很有希望，但它可能不会得到很好的回报，因为现在我们依赖 Akka 持久性来持久化事件，持久化事件成功/失败的第二个要求仍然是手动的，现在必须维护一个更多的存储（持久化日志等）所以不确定我们是否在这里买了很多东西？

第二种方法需要为这两种情况（传入事件和事件结果）编写持久代码。

第一种方法可能看起来不太有希望。

尽管听起来可能像这样，但我并不打算提出一个听起来像“基于意见”的问题，而是试图就上述方法或其他任何可能适合此处的方法的优缺点提供真正的建议。

仅供参考：此特定应用程序是在播放服务器上运行的播放应用程序，因此使用 Actors 不是问题。

我的应用程序需要记录演员处理的所有消息，minSequenceNr并maxSequenceNr有时在之间重播消息。

akka-persistence 对这个用例有用吗？如果是，如何强制重播日志中的消息？我可以Persistence(actorSystem).journalFor("x")用来获取期刊的 ActorRef 但我不能发送JournalProtocol.ReplayMessages给它，因为它JournalProtocol是私有的akka.persistence。

I have an Akka parent actor with several children. When the parent actor is restarted, I need it to simply stop its children, rather than stopping and re-creating or restarting them. (A child would be created manually later, if it's needed.) Is there a way to do this? Perhaps by overriding the parent's preRestart method in some way?