【问题标题】:RabbitMQ, RPC, and Correlation ID MatchingRabbitMQ、RPC 和相关 ID 匹配
【发布时间】:2019-10-30 03:15:24
【问题描述】:

我正在关注其中一个 RabbitMQ RPC 教程 (https://www.rabbitmq.com/tutorials/tutorial-six-dotnet.html),但对 Correlation ID 匹配感到有些困惑。

教程指出:

此时使用 CorrelationId 属性。我们将为每个请求将其设置为唯一值。稍后,当我们在回调队列中收到一条消息时,我们将查看此属性,并基于此将响应与请求进行匹配。如果我们看到未知的 CorrelationId 值,我们可以安全地丢弃该消息 - 它不属于我们的请求。

但是为什么在我们已经从队列中消费完消息之后丢弃它是“安全的”呢?期待该消息的客户呢?消息不应该重新排队以防丢失吗?

【问题讨论】:

    标签: rabbitmq rpc


    【解决方案1】:

    听起来很合理。但是在重新排队之后,将无法保证原始消息的发送者会收到它。如果没有更多关于交换、绑定和队列设置的知识,就很难判断重新排队是否有意义。

    上面链接的教程似乎故意没有涵盖这个复杂的问题。我认为这超出了指导读者如何在技术上使用 RabbitMQ 的 RPC 功能的教程的范围。

    【讨论】:

    • 假设我们有一个简单的场景。一个专用请求队列,专用响应队列,默认交换器,1 个客户端,1 个服务器。客户端正在并行发出 RPC 请求(例如管理跨线程同时请求的 Web 服务器)。我如何保证每个请求者都会收到他们想要的响应?我过去通过为每个请求创建一个队列来解决这个问题,但这似乎效率低下。
    • 每个请求者的队列怎么样?
    • 如果 Web 服务器同时收到 10 个请求,这将导致 10 个线程、10 个请求者和 10 个临时队列用于回复。这就是我现在实现它的方式,并且它有效。我希望找到一个不需要一直启动和拆除临时队列的解决方案。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-04-15
    • 2020-11-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多