RabbitMQ – 消息传送顺序
我需要为我的新项目select一个新的队列代理。
这次我需要一个支持pub / sub的可伸缩队列，并且保持消息顺序是必须的。
我读亚历克西斯评论：他写道：
“的确，我们认为RabbitMQ比Kafka提供更强的订单”
我阅读rabbitmq文档中的消息订购部分：
“消息可以使用AMQP方法（basic.recover，basic.reject和basic.nack）返回队列，也可以由于通道closures而保留未确认的消息。”在2.7.0及更高版本如果队列中有多个用户，那么个人用户仍然可能观察到乱序信息，这是由于其他用户可能需要的消息的行为，从队列的angular度来看，信息总是以发布的顺序进行。 “
如果我需要通过他们的订单来处理邮件，我只能使用rabbitMQ给每个消费者一个排队队列？
RabbitMQ仍然被认为是有序消息队列的一个很好的解决scheme吗？
那么，让我们仔细看一下上面描述的场景。 我认为在问题片段之前立即粘贴文档以提供上下文很重要：
AMQP 0-9-1核心规范的第4.7节解释了保证sorting的条件：在一个频道中发送的消息，按照发送的顺序接收一个交换机，一个队列和一个输出频道。 自2.7.0版本以来，RabbitMQ提供了更强大的保证。
消息可以使用AMQP方法返回到队列，这些方法具有一个requeue参数（basic.recover，basic.reject和basic.nack），或者由于通道closures，同时保存未确认的消息。 任何这些情况都会导致消息在队列的后面重新排队，以便早于2.7.0的RabbitMQ版本发布。 从RabbitMQ版本2.7.0开始，消息总是以发布顺序保存在队列中， 即使存在重载或通道closures。 （强调加）
所以很显然，从2.7.0开始，RabbitMQ在消息sorting上比原来的AMQP规范有了很大的改进。
对于多个（并行）消费者，处理顺序不能得到保证。
第三段（粘贴在问题中）继续给出一个免责声明，我将其解释为：“如果队列中有多个处理器，则不再保证消息将按顺序处理。” 他们在这里所说的是RabbitMQ不能违抗math规律。
考虑银行的一系列客户。 这家银行以自己进入银行的顺序来帮助客户而自豪。 顾客排队等候，并由3名可用出纳员中的下一个出纳员服务。
今天早上，所有三名出纳员同时到达，接下来的三名客户接近。 突然之间，三名出纳员中的第一个病得厉害，不能为第一位客户服务。 到这个时候，柜员2和3开始为顾客2和顾客3服务。
现在，有两件事情可以发生。 （1）在线的第一位顾客可以返回到行首，或者（2）第一位顾客可以抢先第三位顾客，导致该出纳员停止对第三位顾客工作并开始第一位顾客的工作。 RabbitMQ不支持这种抢占逻辑，也不支持我知道的任何其他消息代理。 无论哪种情况，第一个客户实际上并没有最终得到帮助，第二个客户很幸运，他能够从一个好的出纳员那里得到帮助。 保证客户得到帮助的唯一方法就是让一位柜员随时帮助客户，这将给银行带来更大的问题。
我希望这有助于说明你所问的问题。 考虑到你有多个消费者，不可能确保消息在所有可能的情况下都能按顺序处理。 不pipe你是否有多个队列，多个独占消费者，不同的经纪人等等 – 没有办法保证消息被多个消费者顺序地回答。 但是RabbitMQ将尽最大努力。
消息sorting保存在Kafka中，但只在分区内而不是全局内。 如果你的数据需要全局sorting和分区，这确实使事情变得困难。 但是，如果您只需要确保同一用户的所有相同事件等最终在同一个分区中，以便它们被正确sorting，则可以这样做。 生产者负责他们写入的分区，所以如果你能够在逻辑上分割你的数据，这可能是更好的select。
