RabbitMQ高可用--Quorum Queue(仲裁队列)的原理

Dear 丶 2023-09-29 17:11 12阅读 0赞

原文网址：[RabbitMQ高可用--Quorum Queue(仲裁队列)的原理\_IT利刃出鞘的博客-CSDN博客][RabbitMQ_--Quorum Queue_IT_-CSDN]

## 简介 ##

**说明**

本文介绍RabbitMQ的Quorum Queue(仲裁队列)的用法和原理。

RabbitMQ从3.8.0版本开始加入仲裁队列功能，它是镜像队列的替代方案。它有队列复制的能力，保障数据的高可用和安全性。使用仲裁队列可以在 RabbitMQ 节点间进行队列数据的复制，在一个节点宕机时队列仍然可以提供服务。

**官网网址**

[https://www.rabbitmq.com/quorum-queues.html][https_www.rabbitmq.com_quorum-queues.html]

**相关网址**

[RabbitMQ高可用--Quorum Queue(仲裁队列)的用法\_IT利刃出鞘的博客-CSDN博客][RabbitMQ_--Quorum Queue_IT_-CSDN 1]

**备注**

RabbitMQ 已经有一个高可用队列的实现：镜像队列（Mirror Queues）。在 RabbitMQ 3.8.0 版本之前，镜像队列是实现数据高可用的唯一手段，但它有设计缺陷。仲裁队列旨在解决镜像队列的性能和同步问题。

## 仲裁队列的特性 ##

1.  仲裁队列用 Raft 算法实现了持久的、复制的 FIFO 队列，更加专注于数据安全。
    
    1.  不会出现mirror queue出现的那样，两个节点件同一queue的数量落差很大的情况。
    2.  Quorum队列中的消息要有集群中多半节点同意后，才会写到队列。这种队列类似于RocketMQ当中的Ledger集群，这种方式可以保证消息在集群内部不会丢失。
2.  Quorum queue到特定负载后，就不会继续接受新消息了。保持自身的平衡。

## 仲裁队列的使用场景 ##

**使用场景**

1.  队列长期存在
2.  对容错、数据安全方面的要求比较高，能容忍响应慢些
3.  需要持久化

**不适合使用的场景**

1.  一些临时使用的队列：比如transient临时队列，exclusive独占队列，或者经常会修改和删除的队列
2.  对消息低延迟要求高：一致性算法会影响消息的延迟
3.  对数据安全性要求不高：Quorum队列需要消费者手动通知或者生产者手动确认
4.  队列消息积压严重：如果队列中的消息很大，或者积压的消息很多，就不要使用Quorum队列。Quorum队列当前会将所有消息始终保存在内存中，直到达到内存使用极限。

## 仲裁队列和镜像队列的对比 ##

<table> 
 <tbody> 
 <tr> 
 <td style="vertical-align:top;"> Feature </td> 
 <td style="vertical-align:top;"> Classic Mirrored </td> 
 <td style="vertical-align:top;"> Quorum </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> <a href="https://www.rabbitmq.com/queues.html" title="Non-durable queues" rel="nofollow">Non-durable queues</a> </td> 
 <td style="vertical-align:top;"> yes </td> 
 <td style="vertical-align:top;"> no </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> <a href="https://www.rabbitmq.com/queues.html" title="Exclusivity" rel="nofollow">Exclusivity</a> </td> 
 <td style="vertical-align:top;"> yes </td> 
 <td style="vertical-align:top;"> no </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> Per message persistence </td> 
 <td style="vertical-align:top;"> per message </td> 
 <td style="vertical-align:top;"> always </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> Membership changes </td> 
 <td style="vertical-align:top;"> automatic </td> 
 <td style="vertical-align:top;"> manual </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> <a href="https://www.rabbitmq.com/ttl.html" title="Message TTL (Time-To-Live)" rel="nofollow">Message TTL (Time-To-Live)</a> </td> 
 <td style="vertical-align:top;"> yes </td> 
 <td style="vertical-align:top;"> yes (<a href="https://blog.rabbitmq.com/posts/2022/05/rabbitmq-3.10-release-overview/" title="since 3.10" rel="nofollow">since 3.10</a>) </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> <a rel="nofollow">Queue TTL</a> </td> 
 <td style="vertical-align:top;"> yes </td> 
 <td style="vertical-align:top;"> yes </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> <a href="https://www.rabbitmq.com/maxlength.html" title="Queue length limits" rel="nofollow">Queue length limits</a> </td> 
 <td style="vertical-align:top;"> yes </td> 
 <td style="vertical-align:top;"> yes (except&nbsp;x-overflow:&nbsp;reject-publish-dlx) </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> <a href="https://www.rabbitmq.com/lazy-queues.html" title="Lazy behaviour" rel="nofollow">Lazy behaviour</a> </td> 
 <td style="vertical-align:top;"> yes </td> 
 <td style="vertical-align:top;"> always (since 3.10) or through the&nbsp;<a rel="nofollow">Memory Limit</a>&nbsp;feature (before 3.10) </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> <a href="https://www.rabbitmq.com/priority.html" title="Message priority" rel="nofollow">Message priority</a> </td> 
 <td style="vertical-align:top;"> yes </td> 
 <td style="vertical-align:top;"> no </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> <a href="https://www.rabbitmq.com/consumer-priority.html" title="Consumer priority" rel="nofollow">Consumer priority</a> </td> 
 <td style="vertical-align:top;"> yes </td> 
 <td style="vertical-align:top;"> yes </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> <a href="https://www.rabbitmq.com/dlx.html" title="Dead letter exchanges" rel="nofollow">Dead letter exchanges</a> </td> 
 <td style="vertical-align:top;"> yes </td> 
 <td style="vertical-align:top;"> yes </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> Adheres to&nbsp;<a rel="nofollow">policies</a> </td> 
 <td style="vertical-align:top;"> yes </td> 
 <td style="vertical-align:top;"> yes (see&nbsp;<a rel="nofollow">Policy support</a>) </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> Poison message handling </td> 
 <td style="vertical-align:top;"> no </td> 
 <td style="vertical-align:top;"> yes </td> 
 </tr> 
 <tr> 
 <td style="vertical-align:top;"> Global&nbsp;<a rel="nofollow">QoS Prefetch</a> </td> 
 <td style="vertical-align:top;"> yes </td> 
 <td style="vertical-align:top;"> no </td> 
 </tr> 
 </tbody> 
</table>

**Poison Message(有毒的消息)**

这个是指消息一直不能被消费，就会导致消息不断的重新入队，这样这些消息就成为了毒消息。对于毒消息的处理，在经典队列中，可以通过设置入队次数上限的参数，将消息最终转入到死信队列处理，而在Quorum队列中，就有了更新的处理方式。

## 仲裁队列的优势 ##

1.  客户端不需要改变它们生产和订阅的方法，无需考虑队列类型。
    
    1.  唯一的区别就是在客户端定义队列的时候需要定义成仲裁队列（代码中添加相关属性）
2.  被解决当节点重新上线时，不会丢数据（解决了镜像队列同步的问题）
    
    1.  主副本会直接从从副本中断的地方开始复制消息。复制的过程是非阻塞的，所以整个队列不会因为新的副本加入而收到影响。唯一的影响是网络使用率。
    2.  没有了同步问题，不仅让仲裁队列比镜像队列更可靠，同时，因为写入必须被超过半数的副本接受，所以不会因为脑裂而丢数据。
3.  Raft 协议比镜像队列的算法更有效率，可以提供更好的消息吞吐量。

总结起来，仲裁队列可以提供更高的性能、更好的数据安全性、更容易进行节点的滚动升级。

## 仲裁队列的劣势 ##

#### 特性更少 ####

这些特性在仲裁队列的第一个版本中不会提供

1.  非持久化消息
2.  排它队列
3.  队列/消息 TTL（超时时间）
4.  一些规则（Policy）不可用，只有死信队列、队列长度限制可用
5.  优先级
6.  惰性队列
7.  非全局的消息预取（Qos）

#### 磁盘使用——写入放大 ####

仲裁队列的磁盘和内存配置与普通队列不同。

**普通队列**

普通队列使用“共享”存储模型，对于一条要投递到多个队列的消息，只会存储一次，其他队列只会保存这条消息的引用。也就是说，在发布-订阅模型下，一条将要投递到多个队列的消息，它的存储大小不会随着投递到的队列变多而线性增长。

举个例子，我们用一个 fanout 类型的 exchange，绑定 10 个队列。这 10 个队列每个都设置 5个副本镜像队列。发布一条消息后，只有 5 条消息存储到集群中，每个节点存储 1 条。所以在这个情况下的写入放大是 5 倍。

**仲裁队列**

仲裁队列在内存中使用“共享”的存储模型，在磁盘中，每条消息都会分别被存储。所以发布-订阅模型会造成更严重的写入放大，可能导致更大的磁盘使用，甚至不得不放弃使用仲裁队列。

还是上面那个例子，当每个队列都变成仲裁队列，并且复制因子为 5 时，最终集群中的磁盘上存储了 50 条消息，每条消息的写入放大是 50 倍。

因此，把 fanout 交换器和仲裁队列一起使用不太合适。

#### 消息一直在内存中 ####

仲裁队列的所有消息一直会保存在内存中，这会增加内存的使用量，最终可能导致集群不可用。如果不进行一些检查和监控，队列消息不断堆积，可能会导致生产停止（内存高水位），直到消息被消费或者从内存中删除。所以当使用仲裁队列时，设置队列的长度限制非常重要。此外还有必要用惰性队列作为仲裁队列的死信队列，通过死信交换器将这些消息转发到死信队列中。

因此，队列的规划和监控比普通场景更重要。下游（消费者和下游服务）的中断或者变慢可能导致多个队列消息堆积，需要有对应的规划和措施。你需要多少个仲裁队列、它们的写入速率时多少，当集群达到内存高水位时其他队列会不会收到影响？

#### 失去多数节点时队列不可用 ####

如果仲裁队列超过半数的副本永久丢失，那么队列数据就永久丢失了。即便有小部分的副本仍然可用，队列仍然没有办法恢复，只能被强制删除。虽然这种场景出现的可能性较小，但是仍有这样的危险存在。所以，推荐使用可靠的磁盘，并且把复制因子设置为 5 ~ 3。

#### 延迟 ####

尽管仲裁队列的吞吐量更高，但是延迟也可能更高，这是由于使用了 Raft 协议。在仲裁队列中，所有消息都是持久化的，所有消息都会保存到每个副本的磁盘中。安全性是仲裁队列的主要目标。

[RabbitMQ_--Quorum Queue_IT_-CSDN]: https://knife.blog.csdn.net/article/details/126738084
[https_www.rabbitmq.com_quorum-queues.html]: https://www.rabbitmq.com/quorum-queues.html
[RabbitMQ_--Quorum Queue_IT_-CSDN 1]: https://knife.blog.csdn.net/article/details/126740548