akka - 使用 Akka Persistence 和 Extra-Cameo 模式的至少一次交付

Question

我正在开发一个使用 Akka 的应用程序，其中 Actor 旨在避免请求-响应模式。使用 Extra 或 Cameo 模式可以将参与者之间的交互建模为消息“流”。

下图总结了此类参与者的架构。



Cameo 模式用于处理来自 SK 的响应。 Actor 。

现在，想象一下我想保证 SF 之间的至少一次语义。和 SK Actor 。我怎样才能做到这一点？使用 Akka 持久性实现 to 语义需要在这些参与者之间实现请求-响应模式。

如何确保使用 Cameo 处理响应的参与者之间的至少一次语义？

非常感谢

Answer 1

Jamie Allen 在 Twitter 上帮助我回答了这个问题。推特对话是 this .
我尝试总结杰米所说的讨论。

For reliable at-least-once, using Akka Cluster and Persistence to get it done is possible, but probably overkill. I say try to keep it simple. Have a GUID for the request, and send it with the request to the three SKs.

In the immutable ledger scenario, you'd then occasionally sweep the ledger to get rid of dups by GUID. How consistent that data needs to be will define that.

Simplicity is going to be a lot easier to maintain & avoid partial failures. You can handle idempotency on the SK side one of a few ways: either track all GUIDs when the requests are processed via an expiring cache, or store the GUIDs with the immutable updates in a ledger.

因此，在这种情况下，更好的解决方案是完全删除 Akka Persistence 并将问题减少到良好的旧消息传递。 SF发送消息到 SK s 个 Actor ，Cameo 节点等待 SK s 的回应。如果此类 react 未在预定时间窗口内到达，Cameo 节点会发出警报 SF使用超时消息。 SF再次向 SK Actor 重新发送消息。
代表上述解决方案的图表如下。

标有数字 5 的红色消息为超时消息建模。
正如杰米所说:

I think ACK has to be the responsibility of the caller, all the way back to the sender of the original request. That’s the safest & simplest approach.

希望能帮助到你。