使用 akka-persistence 实现 CQRS + 事件溯源答案

【问题标题】：CQRS + Event Sourcing implementation using akka-persistence使用 akka-persistence 实现 CQRS + 事件溯源
【发布时间】：2014-04-23 21:42:41
【问题描述】：

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

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

直接连接EventsourcedProcessor -> View，View直接从journal接收所有事件。这似乎是最简单的解决方案，但我想知道我们是否可以使用这种方法将处理器和视图分布在不同的节点上。
EventsourcedProcessor -> 通道 -> 视图/普通 Actor。与第一个选项有什么区别？如果这是正确的解决方案，为什么我们在 akka-persistence 构建块中有视图？我应该使用 Channels 还是 PersistentChannels ？
EventsourcedProcessor -> 某种事件总线（例如 context.system.eventStream） -> 视图/Actor。

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

【问题讨论】：

有关使用 Akka Persistence Query 和 Akka Streams 的更新答案，请参阅stackoverflow.com/a/42941900/2113120

标签： akka cqrs event-sourcing akka-persistence

【解决方案1】：

EventsourcedProcessor -> 视图是这样做的方法。视图从日志重放，因此在将视图放置在另一台机器上时需要分布式日志。日志实现列表可以在这里找到：http://akka.io/community/

【讨论】：

谢谢！你能解释一下为什么会这样吗？涵盖所有不良情况似乎是合理的方法（例如，具有视图的节点重新启动，询问日志中的所有事件并重播它们）但我有点担心它会损害集群正常状态下的性能。我认为将事件推送到某种事件总线比一直向期刊询问事件更轻量级和分发友好。我的理解是否遗漏了什么？为什么选择期刊作为处理器和视图之间的连接点？
对于特定用例可能有更有效的方法，但您必须考虑以下事项：启动新视图、写入端和读取端之间的解耦、消息丢失、消息排序、重复。所有这些都可能是分布式发布-订阅架构中的难题。

【解决方案2】：

我还发现很难找到任何关于如何处理 Akka 持久性和事件溯源的好例子。因此，我使用 Dropwizard 和 Akka Persistence 创建了这个示例应用程序，akka-persistence-java-example

本示例使用PersistenceActor 写入数据，使用PersistenceQuery 读取数据。

【讨论】：

【解决方案3】：

虽然我认为阅读 EP 的日志是恢复/重建视图的好方法，但它似乎是在轮询日志 (akka.persistence.view.auto-update-interval)。如果想要同步更新读取模型（有人建议这可能是读取模型的一个很好的起点），这将是不合适的。我会建议（并且喜欢自己使用）该期刊进行恢复，但有某种用于现场活动的 pub-sub 架构。我知道这可能很难，但这似乎是正确的做法。但是，我没有足够的知识来建议如何使用 Akka Persistence 或其他库进行分布式发布订阅，甚至无法确定这样做是否真的可行。

作为替代方案，是否可以在他们关注的期刊更新时通知视图？

【讨论】：

【解决方案4】：

关于这个话题的讨论真的很好。我只是粘贴结论帖子https://groups.google.com/forum/#!topic/akka-user/MNDc9cVG1To。希望它可以帮助读者登陆这篇文章。

【讨论】：