在用Akka重写不推荐的persistentView的过程中,我有一个读取参与者需要快照它的状态,日志事件偏移量到目前为止已经读取了。为了停止需要序列化以下复合数据结构的视图参与者:(state +偏移量),我将快照偏移值的责任委托给子参与者。因此,问题是同步这两者之间的偏移值。目前在读演员,我有:
case RecoveryCompleted ⇒
implicit val ec = context.dispatcher
val lastSequenceNr = (sequenceSnapshotterRef ? GetLastSnapshottedSequenceNr).mapTo[QueryOffset]
lastSequenceNr onComplete {
case Success(QueryOffset(sequenceNr)) ⇒
offsetForNextFetch = sequenceNr
doSomethingBasedOnThecompositeData()
...要更新子演员的偏移值以同步快照,我需要:
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.")
}
}但是,这意味着,如果子演员的确认丢失,或者子参与者在发送消息之前死亡,然后视图参与者在等待子参与者的offsetUpdated响应时死亡,则当父参与者试图恢复时,偏移量和状态将处于不同步状态。
这是问题的全部上下文。
Update:阅读更多关于消息传递可靠性的内容,我意识到这是一个更普遍的问题。我能否将此父和参与者配置为使用at-least-once传递机制,而我的项目的其余部分则使用默认的at-most-once传递机制?这仍然不能解决子角色在尝试将确认消息发送回父程序之前就已经死亡的问题。
发布于 2020-09-27 17:12:10
我建议使用ask作为持久化的保证,以及Akka的死亡表。这仍然是不平凡的:仍然存在许多漏洞。
Akka也确实有一次保证,但总的来说,我所做的是:在确认完成之前,将请求发送出去。有规律的告知,我把状态保存在发送者。超时由调度程序处理。
如果孩子死了,对终止的人做出反应,然后继续循环。
https://stackoverflow.com/questions/45353244
复制相似问题