只是想知道从持久事件源参与者到Lagom 中读取处理器的事件通知传递的保证，是否有任何或没有消息持久性事件通知到读取处理器会更新查询端？
我知道有最终的一致性，这很好，但我说的是向 Cassandra 读取处理器发送的事件处理程序通知。
通过在持久实体中使用事件溯源并在读取端处理中使用偏移跟踪来保证事件处理。
当持久实体命令处理程序保留事件时，每个事件都使用有序的"偏移量"存储。
读取端处理器的工作原理是轮询数据库中偏移量大于已处理的最后一个偏移量的事件。由于所有事件和每个读取端处理器的最新偏移量都保留在数据库中，因此这可确保即使读取端处理器崩溃并重新启动，也不会错过事件。
Lagom的Cassandra读侧处理器返回一个CompletionStage或Future，生成CassandraBoundStatement实例的列表，这些实例与偏移量更新一起在原子批处理更新中执行。只要读取端事件处理程序的所有效果都捕获在其生成的更新列表中，这就可以确保事件将得到有效处理一次：如果部分更新失败，将自动重试。
如果要在事件处理程序中执行任何其他操作，则需要确保偏移量更新仅在事件处理程序成功时发生。事件处理程序返回的CompletionStage或Future只能在副作用完成后完成，并且应传播操作的成功或失败。请注意，如果未更新偏移量，将重试事件处理程序，因此，例如，如果事件处理程序与外部服务交互，则需要确保它是幂等的。
您还应该了解最终一致性如何影响事物。akka-persistence-cassandra配置参考包含一些详细信息：
返回的事件流按偏移量(时间戳)排序，该偏移量对应于 与写入日志存储事件的顺序相同，由于时钟偏差而不准确 在不同节点之间。为多个返回相同的流元素(以相同的顺序) 尽最大努力执行查询。查询正在使用 Cassandra 具体化 查看查询，并且最终是一致的，因此不同的查询可能会看到不同的查询 最新事件的事件，但最终结果将按时间戳排序 (Cassandra timeuuid专栏)。为了补偿最终的一致性，查询是 延迟为不读取最新事件，此延迟的持续时间由此定义 配置属性。
但是，这只是尽力而为，并且在网络分区的情况下 或其他可能延迟事件可能延迟实例化视图更新的事情 以不同的顺序交付(不严格按其时间戳)。
重要的结果是，如果最终一致性的延迟长于配置的最终一致性延迟(可能是由于 Cassandra 节点之间的网络分区)，则事件有可能"丢失"。读取端处理程序可能已经处理了较新的事件，并在较旧的事件传递到它正在从中读取的节点之前存储了其偏移量。您可能需要相应地调整配置。