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

.

我试着总结杰米所说的讨论.

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演员发送消息,Cameo节点等待SKs响应.如果此类反应未在预定的时间窗口内到达,则Cameo节点使用超时消息警告SF. SF再次向SKs演员重新发送消息.

代表上述解决方案的图表如下.

标有数字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.

希望能帮助到你.