正在重写已弃用的 persistentView
在 Akka 中,我有一个读取参与者需要对其状态进行快照,并且到目前为止已读取日志事件偏移量。为了停止需要序列化以下复合数据结构的 View Actor:(状态 + 偏移量),我将快照偏移值值的责任委托(delegate)给子 Actor。然后问题是在这两者之间同步偏移值。目前在阅读 Actor 中,我有:
case RecoveryCompleted ⇒
implicit val ec = context.dispatcher
val lastSequenceNr = (sequenceSnapshotterRef ? GetLastSnapshottedSequenceNr).mapTo[QueryOffset]
lastSequenceNr onComplete {
case Success(QueryOffset(sequenceNr)) ⇒
offsetForNextFetch = sequenceNr
doSomethingBasedOnThecompositeData()
...
并更新子 Actor 的偏移值以同步快照,我这样做:
case RequestSnapshot ⇒
implicit val ec = context.dispatcher
val offsetUpdated = sequenceSnapshotterRef ?
QueryViewSequenceApi.UpdateSequenceNr(offsetForNextFetch)
offsetUpdated map {
_ ⇒
saveSnapshot()
snapshotRequested = false
} recover{
case _ ⇒
self ! RequestSnapshot
log.debug("QueryViewSequenceSnapshotter not reachable. Will try again.")
}
}
然而,这意味着如果子actor的确认丢失或者子actor在发送消息之前死亡,那么 View actor在等待
offsetUpdated
时死亡。来自子actor的响应,当父actor尝试恢复时,偏移量和状态将处于未同步状态。这是完整的context的问题。
更新 : 在 message delivery reliability 上阅读更多内容,我意识到这是一个更普遍的问题。我可以将此父级和参与者配置为使用
at-least-once
交付机制,而我的项目的其余部分使用默认 at-most-once
交付机制?在尝试将确认消息发送回 parent 之前,这仍然无法解决子 Actor 死亡的问题。
最佳答案
我建议使用 ask 来获得持久性保证,以及 Akka 的死亡守望。它仍然不是微不足道的:仍然存在许多漏洞。
Akka 也有完全一次的保证,但总的来说,我所做的是:在确认完成之前发出请求。定期告诉,我在发件人中保持状态。超时由调度程序处理。
如果 child 死了,对 Terminated 使用react,然后继续循环。
关于synchronization - Akka:两个 Actor 之间同步状态的正确模式,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45353244/