标签: reliable-message-delivery

我正在开发一个使用Akka的应用程序,其中Actors旨在避免请求 - 响应模式.使用Extra或Cameo模式可以将actor之间的交互建模为消息的"流".

下图总结了这些演员的架构.

Cameo模式用于处理来自SK演员的响应.

现在,假设我要保证在-至少一次的语义SF和SK演员.我怎样才能做到这一点？使用Akka持久性实现ato语义需要在这些actor之间实现请求 - 响应模式.

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

非常感谢

我有一个用于 Azure 函数的 Cosmos DB 触发器。我想将传入文档中的一些数据展平并写入（Azure）SQL Server。

有什么方法可以保证至少一次交货？

我查看了https://hackernoon.com/reliable-event-processing-in-azure-functions-37054dc2d0fc，它在事件中心事件触发的 Azure 函数的情况下提供了一些选项，但我不确定是否相同适用于导致触发器触发的 CosmosDB changefeed。

在 Cosmos DB Change Feed 站点https://docs.microsoft.com/en-us/azure/cosmos-db/change-feed 上，它指出：

对文档的每次更改在更改提要中只出现一次，并且客户端管理其检查点逻辑。更改提要处理器库提供自动检查点和“至少一次”语义。

这是否意味着它实现了与事件中心相同（或类似）的检查点系统？

如果将断路器模式应用于此 CosmosDB 触发器到 Azure 函数的流程，如https://hackernoon.com/reliable-event-processing-in-azure-functions-37054dc2d0fc末尾所详述，断路器模式的工作方式是否相同？

我需要构建一个使用发布/订阅总线的系统(例如Mule,ZeroMQ,RabbitMQ),但是文献都暗示订阅者应用程序可靠地用于接收Pub/Sub总线上他们订阅的主题的消息能够传递信息.

我有一个系统,其中一些应用程序将可靠地连接到发布/订阅总线,但其他应用程序将不会处于活动状态或始终连接到总线.

显而易见的解决方案是在不可靠的应用程序和发布/订阅总线之间建立某种"存在"协议,以便"当前"应用程序立即传递其消息,并且"不存在"应用程序将其消息排队在持久缓冲区中在某种情况下,一旦完成"在线握手",排队的消息就会被传递给新呈现的应用程序.

是否有任何内置此类功能的发布/订阅总线,或者是否有任何开源附加组件可以执行此操作？你能指点我描述这个的任何网址吗？

对于我正在进行的项目,我使用Redis来跨多个进程分发消息.现在,我应该让它们变得可靠.

我考虑通过BRPOPLPUSH命令使用Reliable队列模式.此模式表明处理线程在作业成功完成后,通过lrem命令从"处理列表"中删除了额外的消息副本.

当我使用多个线程弹出时,弹出项的额外副本将从多个线程进入处理列表.也就是说,处理队列包含由多个线程弹出的元素.因此,如果线程完成其作业,则无法知道要从"处理队列"中删除哪个项目.

为了克服这个问题,我想我应该基于threadId维护多个处理队列(每个线程一个).所以,我的BRPOPLPUSH将是:

BRPOPLPUSH <primary-queue> <thread-specific-processing-queue>

然后,为了清理timedout对象,我的监视线程必须监视所有这些特定于线程的处理队列.

对于这个问题,有没有比上面提出的方法更好的方法？

我听说它说过一次提供完全交付几乎是不可能的。同时，据说TCP提供了有保证的交付。如果TCP不提供完全保证的一次传送，那么它将提供最多一次或至少一次

我有一个服务 AAA，每分钟向 RabbitMQ 交换发布 10 到 5 万条消息。.NET Core 服务 BBB 订阅一个队列（所有消息都路由到该队列），并为每条消息调用另一个通过 Internet 的 HTTP 服务 CCC。问题是 CCC 非常不可靠，每天有几次它会完全关闭一两分钟，每周至少有一次它会关闭一个小时。

我无法控制 AAA 或 CCC。如何使用 RabbitMQ 路由功能可靠地传递所有消息？