Rabbitmq 为了确保并发性，同一组工作在多个队列中（FIFO）

我有一个关于多消费者并发的问题。 我想将来自web请求的工作发送到rabbitmq到分布式队列。 我只是想确定多队列（FIFO）中的工作顺序。 由于此请求来自不同的用户，因此必须订购每个用户请求/作品

我在Azure ServiceBus和ActiveMQ消息分组中发现此功能具有不同的名称

有什么办法可以在漂亮的兔子身上做到这一点吗

我想确认，客户的要求必须相互订购。 每个客户可能有多个请求，但必须按顺序处理该客户的请求。 我希望使用不同节点上的多个使用者快速处理传入请求。 例如，1到1000个不同的客户发送超过100万个请求。 如果我只将这个巨大的请求放在一个队列中，则需要花费大量的时间。所以我想在n（5）个节点之间共享这个进程负载。对于客户X，处理请求的顺序必须相同（假设OP询问的是ActiveMQs“消息分组：）

这不是RabbitMQ AFAIK当前内置的（截至2013年，根据），我现在也不知道（尽管我最近没有跟上）

但是，RabbitMQ的交换和队列模型非常灵活—可以轻松地动态创建交换和队列（这可以在其他消息传递系统中完成，但是，例如，如果您阅读ActiveMQ文档或Red Hat AMQ文档，您会发现《用户指南》中的所有示例都在系统启动时加载的配置文件中使用预先声明的队列-类似RPC的请求/响应通信除外）

此外，在RabbitMQ中，消费者（即消息消费线程）很容易从多个队列中消费

因此，您可以在RabbitMQ的基础上构建一个系统，从中获得所需的分组语义

一种方法是创建动态队列：第一次看到客户订单或新的客户订单组时，将为该组的所有消息创建一个具有唯一名称的队列-该队列名称将（通过另一个队列）进行通信对于唯一目的是在负责处理客户订单组的其他消费者之间实现负载平衡的消费者，即负载平衡器会从其队列中拉出一条消息，上面写着“队列名称为XYZ的新组”它将在订单组消费者池中找到一个消费者，该消费者可以接受此负载并向其传递一条消息，说“开始收听XYZ”

---

另一种方法是使用发布/订阅和主题路由-每个客户订单组将获得一个唯一的主题-并按上述方式进行处理。

当使用基于事件的系统时，尤其是使用多个生产者和/或消费者时，重要的是要接受这样一个事实，即通常没有保证订单为了得到一个健壮的系统，明智的做法是将系统设计为消息处理程序是幂等的；它们应该允许获得相同的消息两次（或更多）

有很多事情可能（实际上应该被允许）干扰秩序

• 制作人可能会以稍微不同的速度传递信息
• 一个生产者可能会错过一个ack（由于错过了一个包），并将重新发送该消息
• 一个消费者可能会收到并处理一条消息，但ack在返回的过程中丢失，因此该消息会被传递两次（到另一个消费者）
• 处理程序所依赖的其他服务可能已关闭，因此您必须拒绝该消息

也就是说，servicebus系统（如servicebus系统）使用一种模式来强制使用订单消息。有一些要求：

• 您需要一个允许有条件更新的集中式存储（如sql server或文档存储）；例如，您希望能够存储上次处理的消息的序列号（或您在该过程中的完成程度），但前提是已经存储的序列/进度是正确的/预期的。存储用户id和进度对于大多数数据库来说应该是非常容易的操作，即使对于数百万客户也是如此
• 请确保该队列配置了用于重试的，然后再次将原始队列设置为该队列的死信队列
• 您在重试/死信队列上设置了TTL（例如30秒）。这样，死信队列上显示的消息将在超时后自动推回到原始队列
• 处理邮件时，请检查存储/数据库是否处于正确的状态以处理邮件（即，前面所需的步骤已经完成）。
  • 如果您可以处理它，您可以这样做并（有条件地）更新存储
  • 如果没有，你就对消息进行nack，这样它就会被抛出死信队列。基本上你说的是“不，我不能处理这个消息，队列中可能还有其他消息需要首先处理”

通过这种方式，快乐的途径是以正确的顺序处理大量消息。 但是，如果发生了什么事情，并且您在带外收到了一条消息，您将把它扔到重试队列（死信队列）上，Rabbit将确保它将返回队列，以便在稍后的阶段重试。但仅在延迟之后

---

这句话的意思是，你可以处理大多数可能干扰消息处理的情况（无序消息，依赖服务被关闭，处理程序在处理消息的过程中被关闭），通过拒绝消息和让你的基础设施（兔子）请注意稍后重试。

RabbitMQ一致哈希交换类型

我们正在使用RabbitMQ，我们发现了一个插件。