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