Bic*_*ick 48 queue message-queue rabbitmq
我需要为我的新项目选择一个新的队列代理.
这次我需要一个支持pub/sub的可伸缩队列,并且必须保持消息排序.
我读过亚历克西斯的评论:他写道:
"事实上,我们认为RabbitMQ比Kafka提供更强的订购"
我在rabbitmq docs中阅读了消息订购部分:
"消息可以使用AMQP方法返回队列,这些方法具有重新排队参数(basic.recover,basic.reject和basic.nack),或者由于在保留未确认的消息时关闭了通道...使用2.7.0及更高版本它仍然有可能为个人消费者,观察消息无序如果队列中有多个用户.这是因为谁可能重新排队消息的其他用户的行为.从队列中的消息总是在发布顺序举行的视角. "
如果我需要按订单处理消息,我只能使用带有独占队列的rabbitMQ给每个消费者吗？
RabbitMQ仍然被认为是有序消息排队的一个很好的解决方案吗？
the*_*yer 117
那么,让我们仔细看看你上面描述的场景.我认为在问题的片段之前粘贴文档以提供上下文非常重要:
所述AMQP 0-9-1核心规范的第4.7节解释根据该排序是有保证的条件:发表于一个信道的消息,通过一个交换和一个队列和一个输出信道将在相同的顺序,它们被送往接收.自2.7.0发布以来,RabbitMQ提供更强大的保障.
可以使用具有重新排队参数(basic.recover,basic.reject和basic.nack)的AMQP方法将消息返回到队列,或者由于在保留未确认的消息时关闭通道.任何这些情况都会导致消息在早于2.7.0的RabbitMQ版本的队列后面重新排队.从RabbitMQ版本2.7.0开始,消息始终以发布顺序保存在队列中,即使存在重新排队或通道关闭.(重点补充)
因此,很明显,从2.7.0开始,RabbitMQ在消息排序方面对原始AMQP规范进行了相当大的改进.
对于多个(并行)消费者,无法保证处理顺序.
(在这个问题粘贴)第三段接着给出一个声明,我将意译:"如果你在队列中多个处理器,不再有保证的消息将按顺序进行处理." 他们在这里所说的只是RabbitMQ无法违反数学定律.
考虑银行的一系列客户.这家银行以帮助客户进入银行的顺序而自豪.客户排队等候,并由3个可用柜员中的下一个提供服务.
今天早上,所有三名柜员同时出现,接下来的三位顾客接近了.突然之间,三名计票员中的第一名患者病情严重,无法完成服务第一位客户.到发生这种情况时,柜员2已完成客户2,柜员3已经开始为客户3服务.
现在,有两件事情可能发生.(1)在第一线的客户可以去回行或(2)的第一个客户可以抢先第三客户的头部,导致该柜员停止第三客户工作,开始的第一个工作日.RabbitMQ不支持这种类型的抢占逻辑,也不支持我知道的任何其他消息代理.在任何一种情况下,第一个客户实际上并没有最终获得帮助 - 第二个客户确实如此,幸运地获得了一个好的,快速的出纳员.保证客户得到帮助的唯一方法是帮助一个柜员一次一个地帮助客户,这将导致银行的主要客户服务问题.
我希望这有助于说明您所询问的问题.鉴于您有多个消费者,不可能确保在每种可能的情况下按顺序处理消息.如果你有多个队列,多个独家消费者,不同的经纪人等等都没关系 - 没有办法保证先前消息是按照多个消费者的顺序回答的.但RabbitMQ将尽最大努力.
小智 7
消息排序在Kafka中保留,但仅在分区内而不是全局内.如果您的数据需要全局排序和分区,这确实会让事情变得困难.但是,如果您只需要确保同一个用户的所有相同事件......最终都在同一个分区中,以便正确排序,您可以这样做.生产者负责他们写入的分区,因此如果您能够对数据进行逻辑分区,则这可能更为可取.
我认为这个问题中有两件事不相似，消费订单和处理订单。
消息队列可以在一定程度上保证消息将按顺序消费，但是，它们不能保证消息的处理顺序。
这里的主要区别在于消息处理的某些方面在消费时无法确定，例如：
如前所述，消费者在处理过程中可能会失败，这里消息的消费顺序是正确的，但是，消费者未能正确处理它，这将使其返回队列，直到现在消费顺序仍然完整，但我们没有'不知道现在处理顺序如何
如果“处理”是指消息现在被丢弃并完全完成处理，那么请考虑您的处理时间不是线性的情况，换句话说，处理一条消息的时间比处理另一条消息的时间长，因此如果消息 3 的处理时间比预期，那么消息 4 和 5 可能会在消息 3 之前被消费并完成处理
因此，即使您设法将消息返回到队列的前面（顺便说一下，这违反了消费顺序），您仍然无法保证下一条消息之前的所有消息都已完成处理。
如果要确保处理顺序，则：
| 归档时间： |
|
| 查看次数： |
38378 次 |
| 最近记录： |