我正在开发一个使用 Akka 的应用程序,其中 Actors 旨在避免请求-响应模式。使用 Extra 或 Cameo 模式可以将参与者之间的交互建模为消息的“流”。
下图总结了此类参与者的架构。
Cameo 模式用于处理来自SK
参与者的响应。
现在,假设我想保证和演员之间的至少一次语义。我怎样才能做到这一点?使用 Akka 持久性实现ato语义需要在这些参与者之间实现请求-响应模式。SF
SK
如何确保使用 Cameo 处理响应的演员之间的至少一次语义?
非常感谢
我正在开发一个使用 Akka 的应用程序,其中 Actors 旨在避免请求-响应模式。使用 Extra 或 Cameo 模式可以将参与者之间的交互建模为消息的“流”。
下图总结了此类参与者的架构。
Cameo 模式用于处理来自SK
参与者的响应。
现在,假设我想保证和演员之间的至少一次语义。我怎样才能做到这一点?使用 Akka 持久性实现ato语义需要在这些参与者之间实现请求-响应模式。SF
SK
如何确保使用 Cameo 处理响应的演员之间的至少一次语义?
非常感谢
Jamie Allen 在 Twitter 上帮助我回答了这个问题。推特对话是这样的。
我试着总结一下 Jamie 所说的讨论。
对于可靠的至少一次,使用 Akka Cluster 和 Persistence 来完成它是可能的,但可能有点矫枉过正。我说尽量保持简单。拥有请求的 GUID,并将其与请求一起发送到三个 SK。
在不可变账本场景中,您有时会扫描账本以通过 GUID 清除重复数据。数据需要的一致性将定义这一点。
简单性将更容易维护并避免部分故障。您可以通过以下几种方法之一在 SK 端处理幂等性:在通过过期缓存处理请求时跟踪所有 GUID,或者将具有不可变更新的 GUID 存储在分类帐中。
因此,在这种情况下,更好的解决方案是完全删除 Akka Persistence,并将问题减少到良好的旧消息传递。
SF
向 s 演员发送消息SK
,Cameo 节点等待SK
s 响应。如果此类反应未在预定的时间窗口内到达,Cameo 节点SF
将使用超时消息发出警报。SF
再次向 SK 演员重新发送消息。
代表上述解决方案的图表如下。
标有数字 5 的红色消息模拟了超时消息。
正如杰米所说:
我认为ACK必须是调用者的责任,一直回到原始请求的发送者。这是最安全和最简单的方法。
希望能帮助到你。