问持久性参与者和读取处理器之间的Lagom消息持久性

EN

通过在持久实体中使用事件源和在读取端处理中使用偏移跟踪来保证事件处理。

当您的持久性实体命令处理程序持续存在事件时，每个事件都存储在一个有序的“抵消”中。

读取端处理器的工作方式是轮询数据库中的事件，其偏移量大于已处理的上次偏移量。因为所有事件和每个读取端处理器的最新偏移量都保存在数据库中，这确保了即使读取端处理器崩溃和重新启动也不会错过事件。

Lagom的Cassandra读取端处理器返回一个CompletionStage或Future，它生成Cassandra BoundStatement实例的列表，这些实例与偏移量更新一起在原子批处理更新中执行。只要读取端事件处理程序的所有效果都被捕获在它生成的更新列表中，这就确保事件将被有效地处理一次:如果更新的一部分失败，它将被自动重试。

如果在事件处理程序中执行其他操作，则需要确保只有在事件处理程序成功时才会发生偏移更新。事件处理程序返回的CompletionStage或Future必须在副作用完成后才能完成，并且您的操作的成功或失败应该被传播。请注意，如果偏移量未更新，则将重新尝试事件处理程序，因此，如果事件处理程序与外部服务交互，则需要确保它是幂等的。

您还应该意识到最终的一致性会如何影响事物。akka-persistence-cassandra 配置参考有一些详细信息：

返回的事件流由偏移量(时间戳)排序，该偏移量对应于写入日志存储事件的相同顺序，由于不同节点之间的时钟偏差，导致不准确。返回相同的流元素(按相同的顺序)，以便在最大努力的基础上多次执行查询。查询对查询使用的是Cassandra物化视图，这最终是一致的，因此不同的查询可能会看到最新事件的不同事件，但最终结果将按时间戳(Cassandra timeuuid列)排序。为了补偿查询的最终一致性，将查询延迟为不读取最新事件，此配置属性定义了此延迟的持续时间。 但是，这只是最好的努力，对于可能延迟物化视图更新的网络分区或其他事情，事件可以按不同的顺序传递(而不是严格地按时间戳传递)。

重要的结果是，如果最终一致性的延迟比配置的最终一致性延迟更长(可能是由于Cassandra节点之间的网络分区造成的)，则存在“丢失”事件的可能性。读取端处理程序可能已经处理了较新的事件，并在将较旧事件传递到正在读取的节点之前存储其偏移量。您可能需要相应地调整您的配置。