Rabbitmq RPC模型中的correlationId和临时队列-AMQP

我和RabbitMQ一起读AMQP。本教程将创建一个临时队列和

correlationId

。临时队列是唯一的，那么我们为什么需要correlationId呢？我是一名JMS人员，在JMS中，我们通过两种方式进行请求/响应：

为每个请求/响应创建临时队列

创建一个响应队列并使用

correlationId

和消息选择器

---

有人能解释为什么我们需要AMQP RPC模型中的临时队列和

correlationId

吗？AMQP似乎没有类似于消息选择器的功能。我说得对吗？

正确，临时队列对于发出RPC请求的客户端是唯一的。我们可以创建RPC客户端，使其对每个唯一请求都有一个唯一的队列，但这样做效率低下-请参阅CorrelationId的第一段：

在上面介绍的方法中，我们建议为每个RPC请求创建一个回调队列。这是非常低效的，但幸运的是有一个更好的方法——让我们为每个客户端创建一个回调队列

因此，更好的方法是使用一个队列，让RPC客户端返回响应，并使用correlationId将RPC客户端发出的请求与RPC服务器发送回的结果相匹配

…在该队列中收到响应后，不清楚响应属于哪个请求。此时将使用correlation\u id属性。我们将为每个请求设置一个唯一的值。稍后，当我们在回调队列中收到消息时，我们将查看此属性，并基于此，我们将能够将响应与请求相匹配。如果我们看到一个未知的关联id值，我们可以安全地丢弃该消息-它不属于我们的请求

因此，请参考本手册的摘要部分：

• 当客户机启动时，它会创建一个独占且唯一的队列
• 当它发送一个RPC请求时，它会设置作为队列名称的reply_（这样服务器就知道向哪个队列发送响应），并设置一个correlationId，它是每个RPC请求的唯一val
• 请求被发送到RPC队列
• RPC工作者（或服务器）接收请求并处理它，然后使用reply_to值将响应发送回客户端，它还设置correlationId
• RPC客户端等待响应，并在收到响应时使用correlationId将响应与请求匹配

---

丢弃不匹配的邮件如何安全？期待该响应的请求者呢？消息现在丢失，因为有其他东西从队列中消耗了它并将其丢弃。如果您的客户机是一个web服务器，并跨线程传播并行请求，则可能会发生这种情况。在这种情况下，您如何保证消息不会被丢弃的消费者丢失？