简介
If intentionally simplified, quorum in a distributed system can be defined as an agreement between the majority of nodes (
(N/2)+1whereNis the total number of system participants).When applied to queue mirroring in RabbitMQ clusters this means that the majority of replicas (including the currently elected queue leader) agree on the state of the queue and its contents.
仲裁队列基于 Raft 共识算法实现了一个持久的、可副本的 FIFO 队列。
Quorum queues should be the default choice for a replicated queue type. Classic queue mirroring will be removed in a future version of RabbitMQ: classic queues will remain a supported non-replicated queue type.
Quorum队列中的消息要有集群中多半节点同意后,才会写到队列。这种队列类似于RocketMQ当中的Ledger集群,这种方式可以保证消息在集群内部不会丢失。
Quorum vs Classic
https://www.rabbitmq.com/docs/quorum-queues#feature-matrix
不支持队列优先级:手动分级消息,每一级一个队列
永远是惰性队列
永远持久化
永久非排他
用例
何时使用
仲裁队列是专门设计的。它们并不是为了解决所有问题而设计的。它们主要用于队列长期存在且对系统运行的某些方面至关重要的拓扑结构,因此容错和数据安全比尽可能低的延迟和先进的队列功能更重要。
例如,销售系统中的传入订单或选举系统中的投票,其中潜在的消息丢失将对系统的正确性和功能产生重大影响。
股票行情自动收录器和即时通讯系统从仲裁队列中获益较少或根本没有获益。
发布者应使用发布者确认,因为这是客户端与法定人数队列共识系统交互的方式。发布者确认只有在发布的消息已成功复制到法定人数节点,并在系统中被视为 “安全 “时才会发出。
用户应使用手动确认,以确保未成功处理的报文会返回队列,以便其他用户可以重新尝试处理。
何时不用
- 临时队列、排他队列、高队队列流失率(声明和删除率)
- 尽可能低的延迟:由于其数据安全特性,底层共识算法本身具有较高的延迟
- 当数据安全不是优先考虑的时候(例如应用程序不使用手动确认并且不使用发布者确认)
- 队列积压非常长(流可能更适合)
声明队列
x-queue-type
https://www.rabbitmq.com/docs/quorum-queues#configuration
有害消息处理
https://www.rabbitmq.com/docs/quorum-queues#poison-message-handling
副本管理
https://www.rabbitmq.com/docs/quorum-queues#replica-management
默认会有3个副本
队列领导位置 https://www.rabbitmq.com/docs/quorum-queues#leader-placement
https://www.rabbitmq.com/docs/quorum-queues#replica-management
性能调优
https://www.rabbitmq.com/docs/quorum-queues#performance-tuning