Stream Akka:PersistenceQuery如何替代PersistentView？

我们在代码中使用集群单例来减轻读取事件对集群单例的负载。现在，随着

PersistentView

越来越不受欢迎，建议我们使用基于流API的

PersistentQuery

。我们有：

消费参与者可以是普通参与者，也可以是持久参与者 需要存储自己的状态（例如fromSequenceNr偏移量）。 对应的查询类型为EventsTypersistenceId。有 将源连接到参与者的几个备选方案 对应于以前的PersistentView参与者：

我的问题是：

在

PersistentView

中，事件在接收块中处理，我们有一个基于推送的系统。使用

PersistentQuery

，每次调用

eventsTypersistenceId

等类似于拉拽。我将如何模拟演员的连续

receive

行为？我应该这样做吗？这真的是应该使用流的方式吗

我的理解是，每次调用get

EventsByPersistenceId

本质上都是一个查询。因此，执行这些循环查询不是效率低下吗

我还想知道为什么删除了

PersistentView

。这仅仅是一种优化，还是Akka关于迁移到溪流的更广泛行动的一部分，并且有一个范式转变？我试图用

PersistenceQuery

模拟

PersistentView

行为是否犯了错误

我遇到过这样的情况，它似乎在幕后使用

PersistenceQuery

时提供了旧的

PersistentView

功能。基于^中的考虑使用它是否是一个好主意

正如您所提到的，

eventsByPersistenceId

将为您提供Akka Streams

源代码，因此您不太清楚“每个调用”是什么意思。您从这个源定义一个流并将其具体化一次，它将发出新的事件。除其他事项外，您可以将它们发送给参与者，将您的
PersistentView
替换为
mapsync
和
ask
。此方法在和上进行了解释
因此，从参与者的角度来看，它仍然是“基于推送”的，由
receive
处理。
请注意，
mapsync
在第一个参数列表中采用并行系数。要按事件发生的顺序处理事件，应将其设置为“1”（即无并行性）。如果将其设置为更高的值，例如n，则流将接受n个事件并将消息并行发送给参与者，这意味着它们将以随机顺序结束在邮箱中

再说一遍，“每次通话”是什么意思？它很可能只是一个——您在启动时运行/具体化流，它将无限期地流化事件。基本的日志插件实现很可能使用轮询，这是正确的。（我不知道，但我怀疑，

PersistentView

？）也是如此，所以您肯定不想创建大量这些源代码。但如果您对来自多个参与者的事件感兴趣，则更可能标记事件，然后使用

eventsByTag

获取具有给定标记的所有事件的源

当时围绕这一点进行了一些讨论。用我自己的话说，我要说的是，为单个参与者提供视图/读取端的用例并不常见。为了构建基于Akka持久性的CQRS系统，需要一种更强大的方式来消费任何一组事件并以任意方式处理它们，这使得流式查询成为更好的选择。用Akka团队的话来说，设计决策在中进行了解释

我不知道库，即使我知道，如果不知道您的用例，也很难说，即您在接收角色中实际做了什么。就个人而言，我对

PersistenceQuery

很满意，也不认为有必要模拟

PersistentView

，特别是因为将事件从流发送给参与者非常容易，如1所述

---

这演示了

PersistenceQuery

的用法，并使用流API提供了Akka不推荐的

PersistentView

的一个非常轻量级的重新实现。

说到“每次”，我指的是流的每个“物化”（使用runwith/runFor/runFold等）我的理解是，每个具体化都会查询数据库并返回一个流，该流将根据您具体化流的时间而有所不同。我的问题是关于这个物化过程的流程，以及是什么导致了我的参与者持续物化这个流，实际上是“订阅”了它。我现在遇到了

Sink.actorRef

，并且提到了“可恢复流”，我认为这可能与我正在寻找的相关。至于你建议的

mapsync

，我不知道我是否理解这一点。同样，这似乎是一种物质流的味道。我想要的是将其放入一个循环中，以便参与者在其接收块中有效地接收来自所述流的所有消息并对其作出响应。我不明白为什么您要多次具体化“EventsTypersistenceId”或“eventsByTag”。我的方法是将其具体化一次，从而“订阅”期刊事件。我稍微更正了答案，因为当我写“创建源代码”时，我的意思是“运行/具体化流”。请注意，

mapsync

并没有具体化流，它是一种将流与参与者集成的方法。在答案中添加了解释性链接。我明白了。因此，actor接收具有指定持久性ID的所有消息，这些消息不仅在actor生成之前发送，而且在actor死亡之前发送。流在任何时候都不会“完成”。这与我想象的河流作为快照的物质化形成了对比