我在ubuntu-16.04上使用div#wrapperDiv和pika-0.10.0代理。我设计了一个请求/回复服务。有一个请求队列，所有客户端都会推送他们的请求。每个客户端都会创建一个唯一的回复队列：服务器将针对此客户端的回复推送到此唯一队列。我的API可以看作两条消息：rabbitmq-3.6.6和init。
run条消息包含大图片，因此init是一个很大且很慢的请求。 init消息较轻，服务器重用以前的图像。服务器可以为多个客户端服务。通常客户＃1 run然后init多次。如果客户端＃2进入并且run，它将替换服务器上客户端＃1发送的图像。客户端＃1发布的init将使用错误的图像。然后我问：
答案 0 :(得分：1)
我认为您的设计存在问题。逻辑上，每个run对应于某个init，因此必须连接它们。我将相关ID字段放入init和run个事件中。当服务器收到run时，它会检查是否有相应的init已处理并使用init的结果。
说到表现：
您可以创建init工作队列并让多个处理服务器监听它。该示例位于RabbitMQ docs
然后，当init请求进入时，其中一个可用服务器将提取它，并存储您的图像和相关ID。如果您同时有多个init个请求 - 没问题，它们最终会被处理（或者如果服务器空闲则同时处理）
然后执行该过程的服务器向客户端队列发送回复消息，说明init工作已完成，并发送必须发布run请求的队列名称。
准备就绪后，客户端将其run请求发送到正确的队列。
直接回答问题：
您发布到queue时会有一种常见的误解。在RabbitMQ中，您发布到exchange，它关注将消息路由到多个队列。所以你的问题真的变成了can I limit number of publishing connections to an exchange。我很确定在经纪方面无法做到这一点。
即使有一种限制连接数的方法，想象一下情况：
run。init请求。run并获取Client2＆＃39}
图像。连接是一种短暂的事情，不能作为交易机制依赖。