Lagom消息在持久性参与者和读取处理器之间的持久性 [英] Lagom message durability between persistent actor and read processor

问题描述

只是想知道从lagom中持久事件源参与者到事件处理器的事件通知传递的保证，对于通知到读取处理器的事件通知是否存在消息持久性或持久性？

just wondering about the guarantee of the event notification delivery from the persistent event sourced actor to the read processor in lagom , is there any or there is no message durability for event notification to the read processor which will update the query side ?

我知道最终的一致性很好，但是我正在谈论向Cassandra读取处理器发出事件处理程序通知。

I understand there is eventual consistency which is fine but i am talking about the event handler notification to the Cassandra read processor.

推荐答案

通过在持久实体中使用事件源和在读取侧处理中使用偏移量跟踪，可以保证事件处理。

Event processing is guaranteed by using event sourcing in the persistent entity and offset tracking in the read-side processing.

当您的持久实体命令处理程序持久化事件时，每个事件都以有序偏移 。

When your persistent entity command handler persists events, each of the events is stored with an ordered "offset".

读取端处理器通过轮询数据库以查找具有偏移量的事件来工作大于th e已处理的最后一个偏移量。因为所有事件和每个读取侧处理器的最新偏移都保留在数据库中，所以即使读取侧处理器崩溃并重新启动，也可以确保不会丢失事件。

Read-side processors work by polling the database for events with offsets greater than the last offset that has already been processed. Because all events and each read-side processor's latest offset are all persisted in the database, this ensures that events won't be missed even if a read-side processor crashes and restarts.

Lagom的Cassandra读取侧处理器返回 CompletionStage 或 Future ，它们生成Cassandra <$ c $的列表c> BoundStatement 实例，它们在原子批处理更新中与偏移量更新一起执行。只要将读取端事件处理程序的所有效果都记录在它产生的更新列表中，就可以确保事件得到有效处理一次：如果部分更新失败，将自动重试该事件。

Lagom's Cassandra read-side processors return a CompletionStage or Future that produce a list of Cassandra BoundStatement instances, and these are executed in an atomic batch update along with the offset update. As long as all of the effects of your read-side event handler are captured in the list of updates it produces, this ensures that the event will be handled effectively once: if part of the update fails, it will be automatically retried.

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

If you're doing anything else in your event handler, you'll need to be sure that the offset update only happens if your event handler is successful. The CompletionStage or Future the event handler returns must only complete after your side-effect does, and the success or failure of your operation should be propagated. Be aware that your event handler will be retried if the offset is not updated, so if your event handler interacts with an external service, for example, you'll need to be sure it is idempotent.

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

You should also be aware of how eventual consistency can affect things. The akka-persistence-cassandra configuration reference has some details:

返回的事件流按偏移量（时间戳）排序，该偏移量（
）与写入日志存储事件的顺序相同，这是由于不同节点之间的时钟偏斜
导致的不准确性。在尽力而为的情况下，对于查询的多个
执行，将返回相同的流元素（以相同的顺序）。该查询正在使用Cassandra实体化
视图进行查询，并且该查询最终是一致的，因此不同的查询可能会针对最新事件看到不同的
事件，但最终结果将按时间戳
排序。 （Cassandra timeuuid列）。为了补偿最终的一致性，查询被延迟
以便不读取最新事件，此延迟的持续时间由此
配置属性定义。

The returned event stream is ordered by the offset (timestamp), which corresponds to the same order as the write journal stored the events, with inaccuracy due to clock skew between different nodes. The same stream elements (in same order) are returned for multiple executions of the query on a best effort basis. The query is using a Cassandra Materialized View for the query and that is eventually consistent, so different queries may see different events for the latest events, but eventually the result will be ordered by timestamp (Cassandra timeuuid column). To compensate for the the eventual consistency the query is delayed to not read the latest events, the duration of this delay is defined by this configuration property.

但是，这只是尽力而为，并且在网络分区
或其他可能延迟物化视图更新的情况下，事件可能以不同的顺序传递
（并非严格按照其时间戳记进行传递） ）。

However, this is only best effort and in case of network partitions or other things that may delay the updates of the Materialized View the events may be delivered in different order (not strictly by their timestamp).

重要的结果是，如果最终一致性的延迟时间比配置的最终一致性延迟长（可能是由于网络在Cassandra节点之间进行分区），事件有可能丢失。读取侧处理程序可能已经处理了一个较新的事件，并在将较旧的事件传递到要从其读取的节点之前存储了其偏移量。您可能需要相应地调整配置。

The important consequence is that if the latency of eventual consistency is longer than the configured eventual consistency delay (possibly due to a network partition between Cassandra nodes), there is a possibility of events being "lost". A read-side handler may have already processed a newer event and stored its offset before an older event has been delivered to the node that it is reading from. You might need to tune your configuration accordingly.

这篇关于Lagom消息在持久性参与者和读取处理器之间的持久性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！