1.预定义查询
这些查询的具体适用场合和条件，实时流是什么
PersistenceIdsQuery和CurrentPersistenceIdsQuery
PersistenceIds旨在允许用户订阅系统中所有持久性id的流。默认情况下，这个流应该被认为是“实时”流，这意味着期刊在进入系统时应该不断发布新的持久性id：
CurrentPersistenceIdsQuery:不需要实时流，存储事件结束时的相应查询
EventsByPersistenceIdQuery and CurrentEventsByPersistenceIdQuery
EventsByPersistenceIdQuery：重播PersistentActor的查询，但由于它是一个流，故可使其保持活动状态，并监视由给定的persistenceId标识的持久性actor的持续附加传入事件。
CurrentEventsByPersistenceIdQuery：不需要实时流
EventsByTag and CurrentEventsByTag
eventsByTag允许查询事件，而不管它们与哪个persistenceId相关联。该查询很难在某些journal中实施，或者可能需要额外准备使用的数据存储库才能有效执行。此查询的目标是允许查询所有使用特定标签“标记”的事件。这包括用例来查询聚合根类型的所有域事件。
CurrentEventsByTag:不需要实时流(用于查询给定标签标记的查询事件）
journal可以选择对事件进行严格排序，然后应该明确地记录它们提供的订单保证类型 - 例如“通过时间戳升序排序，与persistenceId无关”在关系数据库中很容易实现，但可能很难 在普通键值数据存储上高效实施。
查询物化值
journal能够通过公开Materialized值来提供与查询相关的附加信息，这是Streams的一个特性，允许在实现物流时公开其他值。
更高级的查询日志可以使用这种技术来公开有关物化流特征的信息，例如，如果它是有限的或无限的，严格排序或根本没有排序。物化值类型被定义为返回的Source的第二个类型参数，它允许日记向用户提供他们专用的查询对象，
Resumable projections
可恢复预测是怎么存储的，以及怎么使用
可恢复预测是通过存储处理事件的序列号（或者偏移量），然后在下次投影时使用它吗
ReadJournalProvider类必须有一个具有以下特征之一的构造函数：
//
需要这些构造条件不理解
（1）带有ExtendedActorSystem参数的构造函数，com.typesafe.config.Config参数和配置路径的String参数
（2）带有ExtendedActorSystem参数的构造函数以及com.typesafe.config.Config参数
具有一个ExtendedActorSystem参数的构造函数
（3）没有参数的构造函数
（4）actor系统配置的插件部分将在config构造函数参数中传递。插件的配置路径通过String参数传递。
不理解：如果底层数据存储仅支持在到达
“result set”（“结果集”）末尾时完成的查询，则日记必须在一段时间后提交新查询，以便支持“无限”事件流，其中包含初始查询存储后存储的事件完成。建议插件使用名为refresh-interval的配置属性来定义这样的刷新间隔。
扩展
怎么解决节点奔溃问题？
在事件数量非常大的用例中，每个事件所需的工作量很高，或者弹性很重要，因此如果节点崩溃，持久性查询将在新节点上快速启动，并且可以恢复操作。集群分片与事件标记非常适合集群上的分片事件。
CQRS架构简介
关于CQRS（Command Query Responsibility Segration）架构，大家应该不会陌生了。简单的说，就是一个系统，从架构上把它拆分为两部分：命令处理（写请求）+查询处理（读请求）。然后读写两边可以用不同的架构实现，以实现CQ两端（即Command Side，简称C端；Query Side，简称Q端）的分别优化。CQRS作为一个读写分离思想的架构，在数据存储方面，没有做过多的约束。所以，我觉得CQRS可以有不同层次的实现，比如：
CQ两端数据库共享，CQ两端只是在上层代码上分离；这种做法，带来的好处是可以让我们的代码读写分离，更好维护，且没有CQ两端的数据一致性问题，因为是共享一个数据库的。我个人认为，这种架构很实用，既兼顾了数据的强一致性，又能让代码好维护。CQ两端数据库和上层代码都分离，然后Q的数据由C端同步过来，一般是通过Domain Event进行同步。同步方式有两种，同步或异步，如果需要CQ两端的强一致性，则需要用同步；如果能接受CQ两端数据的最终一致性，则可以使用异步。采用这种方式的架构，个人觉得，C端应该采用Event Sourcing（简称ES）模式才有意义，否则就是自己给自己找麻烦。因为这样做你会发现会出现冗余数据，同样的数据，在C端的db中有，而在Q端的db中也有。和上面第一种做法相比，我想不到什么好处。而采用ES，则所有C端的最新数据全部用Domain Event表达即可；而要查询显示用的数据，则从Q端的ReadDB（关系型数据库）查询即可。
