内容简介：我正在开发一个使用Akka的应用程序,其中Actors旨在避免请求 – 响应模式.使用Extra或Cameo模式可以将actor之间的交互建模为消息的“流”.下图总结了这些演员的架构.
我正在开发一个使用Akka的应用程序,其中Actors旨在避免请求 – 响应模式.使用Extra或Cameo模式可以将actor之间的交互建模为消息的“流”.
下图总结了这些演员的架构.
Cameo模式用于处理来自SK演员的响应.
现在,想象一下,我想保证SF和SK演员之间的至少一次语义.我怎样才能做到这一点？使用Akka持久性实现ato语义需要在这些actor之间实现请求 – 响应模式.
如何确保使用Cameo处理响应的actor之间至少有一次语义？
非常感谢
.
我试着总结杰米所说的讨论.
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.
希望能帮助到你.
翻译自：https://stackoverflow.com/questions/48201333/at-least-once-delivery-using-akka-persistence-and-the-extra-cameo-pattern
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
JSP信息系统开发实例精选
赛奎春 / 机械工业出版社 / 2006-1 / 44.00元
本书精选了大学生就业求职网、物流短信平台、化奥汽车销售集团网站、佳美网络购物中心、科研成果申报管理系统、安瑞奥国际商务不院招生网、明日宽带影院、雄霸天下游戏网等8个综合的网络信息系统工程作为案例，深入剖析了实际的网络信息系统的开发思路、方法和技巧。帮助读者透彻掌握JSP开发网络信息系统的方法和步骤，从而设计出具有实用价值和商用价值的信息系统。 本书产例具有很强的实用性和工程实践性，在讲解......一起来看看 《JSP信息系统开发实例精选》 这本书的介绍吧!
