rabbitmq集群概念讲解

1，集群节点都是对等的，没有所谓主从关系

2，节点命名规则：rabbit@hostname

3，节点之间的数据复制：每个节点的元数据相同【配置信息、用户权限、交换机（exchanges）、绑定（bindings）、虚拟主机（vhosts）】，但是消息队列只存在于其中一个节点中；但是其他节点也能感知到这个队列的存在，且能代理客户端对该队列的请求。

4，集群的形成：我们是通过手动的形式创建的集群

这里的的seed-node种子节点讲的是集群里任何一个节点都可以【保证节点的稳定在线和网络可达】

节点加入之前需要保证节点被重置过且mq应用停止

节点类型：集群必须存在至少一个磁盘节点，且不建议使用内存节点

ram：数据只在内存中存在【4.0版本移除该功能】

disc：数据同时在内存和磁盘中存在【默认的节点类型】

5，集群节点数量

不建议集群只有2个节点，建议使用奇数节点数量：因为只有2个节点的集群，这2个节点失去连接，不能确定多数派，造成共识机制无法工作；因为依赖共识特性才能继续工作。

6，删除集群节点

7，classic queue 经典队列【默认队列类型】

数据不会被复制，数据只存在一个节点里

7.1 特性

queue exclusivity: 队列独占性，队列只能被一个消费者独占使用

queue and message ttl(time-to-live) : 队列与消息的存活时间

过了设置有效的时间后，如果队列为空或者没有收到消息，队列自动被删除

消息可设置存活时间，超出存活时间后，消息自动被删除

quue length limits: 队列的长度限制

message priority: 消息优先级，消息的优先级越高优先被消费

consumer priority: 消费者优先级，一个队列被多个消费者订阅，消费者优先级越高，优先消费消息

adherence to settings controlled using policies: 遵循策略控制的设置，可以使用一套规则配置多个队列，这些规则包括上面讲的一些特性或队列其他的相关属性。

Classic queues support dead letter exchanges (经典队列支持死信交换机)：无法被消费的消息(包括：过期的消息、消息被拒绝且不重新入队、队列达到最大长度)，这些消息称为死信，死信会被自动路由到死信交换机，进而转发至绑定死信交换器的队列中。

poison message handling：毒丸消息，querum queue 仲裁队列支持处理【智能识别毒丸消息，可自动投递死信队列，提供监控警报等功能】

poison message：因数据格式，业务逻辑错误问题反复消费失败的消息

Per-consumer QoS(Quality of Service) prefetch: 消费者的预设值，处理能力强的消费者可以设置大一点

Global QoS prefetch：连接层面的预设值，使用同一个连接的多个消费者使用的预设值，场景适合消费者能力相当【v4.0废弃】

transient queues：临时队列，节点重启队列就会被删除【v4.0废弃】

 lazy mode：懒惰模型，v3.12版本之前消息在被消费者请求时才从磁盘加载到内存，这样可以节约内存，v3.12版本之后根据消费速率动态调整内存中的消息数量。

8，classic queue mirror 经典队列镜像【4.0版本该功能被移除，3.8版本中有querum queue仲裁队列代替】

只有一个leader replica和多个mirrors replica【队列的主副本和队列的辅助副本】

8.1 特性：

队列镜像增强了可用性，但不会跨节点分配负载（所有参与节点各自完成所有工作）

如果承载队列领导者的节点发生故障，只要它是同步的，最旧的镜像将被提升到新的领导者。根据队列镜像参数，也可以提升不同步的镜像。

在分布式系统中，通常有多个术语用于标识主副本和辅助副本。本指南通常使用“leader”表示队列的主副本，使用“mirror”表示辅助副本。

HTTP API和CLI工具中的队列对象字段最初使用了“slave”这个不太合适的术语来指代次队列。该术语仍然出现在CLI工具中的列名中，以实现向后兼容性，但将在未来版本中被替换或删除。

8.2 镜像数量

大部分情况下不需要所有节点都有一个队列副本，大部分节点保留副本即可【n/2+1】

8.3 开启HA高可用集群：配置策略

官方不建议使用all模式，建议使用exactly

8.4 数据同步

ha-sync-batch-size 指定一次同步消息数量

mirroring_sync_batch_size 默认值4096；v3.6版本是1

mirroring_sync_max_throughput 指定每秒传输的字节数，默认值0,表示未开启该功能

8.5 配置同步

ha-sync-mode: manual | automatic

manual: 对于新增的镜像副本，已经存在于主副本消息需要手动同步

automatic：会自动同步已经存在的消息

9，quorom queue 仲裁队列【3.8版本拥有该功能，替换classic queue mirror】

quorum queue 仲裁队列是高可用和数据安全的更好的替代方案

9.1 两者之间的差异

9.1.1 quorum queues与其他类型（包括经典镜像队列）的RabbitMQ队列共享了许多基础特性

9.1.2 quorum queues在设计上更加专注于数据安全性和可预测的故障恢复

数据安全性:  qq致力于确保即使在节点故障、网络分区等复杂场景下，消息也不会丢失，数据一致性得到严格保障。

可预测的恢复: qq在设计上确保了故障发生后的恢复过程是可预测的，即系统能够明确知道哪些消息已提交、哪些消息未提交，以及如何从故障状态恢复到一致状态，从而避免不确定性带来的数据损失风险。

9.1.3 do not support certain features : qq放弃一些功能

9.1.4 Technical Limitations of Classic Mirrored Queues 经典镜像队列存在一些技术局限

保证的清晰度: 经典镜像队列可能难以给出关于数据安全性和一致性的清晰、简洁的保证，这可能使得用户难以准确理解和评估其在各种故障场景下的行为。

故障处理的明确性: 经典镜像队列在处理故障时可能缺乏明确的、易于理解的语义，这可能导致用户在面对故障时难以做出正确的决策，或者在恢复过程中遇到不确定性。

9.1.5 Potential Data Loss in Classic Mirrored Queues 潜在的数据丢失

在某些故障场景下，经典镜像队列可能会过早地确认消息，从而可能导致数据丢失

9.2 声明qq队列

通过客户端设置 x-queue-type：quorum 默认值为classic

也可通过管理页面设置quorum

其他更多相关主题待续....