消息中间件的主要的作用：
1系统解耦
2流量消锋
3数据分发
####### 1.基本
RabbitMQ 开源免费，官方也提供商业特性支持。
用erlang语言开发。RabbitMQ是AMQP（Advanced Message Queuing Protocol，高级消息队列协议）的标准实现。RabbitMQ的broker由Exchange、Binding、queue组成。
是一个传统的消息队列系统，采用了基于消息队列的发布-订阅模型。
设计目标是确保消息的可靠传递，并提供多种消息传递协议的支持
通常用于实时的、对可靠性要求较高的消息传递上
是否支持消息全局有序 ：是。同一队列内消息是有序，按照先进先出原则来存储和消费。但不同队列之间消息是无序的，即不能保证跨队列的消息按照全局顺序来处理
是否支持消息分区有序 ：是
是否支持topic优先级 ：是
是否内置监控 ：是
是否支持多个生产者 ：一个topic支持多个生产者
是否支持多个消费者 ：一个topic支持多个消费者(一个消费者可消费多个分区，一个分区可被多个消费组消费，但同一消费组内仅能有一个消费者同时消费1个分区)
一个分区多个消费者 ： 不支持
是否支持JMX : 不支持(非java语言编写)
是否支持加密 : 支持
消息队列协议 : AMQP、MQTT、STOMP
是否支持消息追踪 : 支持
客户端语言支持 :
是否支持广播消息 ：支持
是否支持消息回溯 ：不支持，消息确认被消费后，会被删除
是否支持消息持久化 ：支持消息数据持久。常用将数据缓存在内存中，支持消息确认和事务机制，以提高可靠性和一致性。RabbitMQ 也可以将数据持久化到磁盘中，但是会降低性能和吞吐量。RabbitMQ 更适合处理小规模且实时性较高的数据。
是否支持消息堆积 ：支持阈值内的消息对接，无法支持较大的消息堆积
是否支持流量控制 ：支持生产者的流量控制
是否支持事务性消息 ：支持。基于AMQP协议
消费者确认机制 ：支持。消费者在接收并处理完消息后向队列发送确认信号，队列才会删除该消息，这样可以保证消息的可靠传递
消息路由 ：支持。支持多种交换机类型，例如直接交换机（direct exchange）、主题交换机（topic exchange）、扇形交换机（fanout exchange）等，以实现不同的消息路由和分发策略
元数据管理 ：
高可用 : 通过镜像（mirror）机制来保证数据的可靠性，即每个队列可以有多个镜像分布在不同的节点上，如果某个节点发生故障，可以自动切换到其他节点
一、 安装
rabbitmq 和 erlang 版本支持对应关系
https://www.rabbitmq.com/docs/which-erlang
https://www.rabbitmq.com/docs/which-erlang#eol-series
历史版本不受支持，只能从github 下载
https://github.com/rabbitmq/rabbitmq-server/releases?expanded=true\&page=3\&q=3.6.15
https://github.com/rabbitmq/erlang-rpm/releases
rongcheng rabbitmq 版本是 3.6.15 ，对应erlang 最小版本是 19.3 ，最大是 20.3.x
rabbitmq 升级
https://www.rabbitmq.com/docs/upgrade
systemctl start rabbitmq-server.service
systemctl status rabbitmq-server.service
1.准备
关闭防火墙
1.配置 hosts vim /etc/hosts
192.168.0.37 rabbitmq-1
192.168.0.38 rabbitmq-2
192.168.0.39 rabbitmq-3
2.同步.erlang.cookie 确保节点间可以通信
/var/lib/rabbitmq/.erlang.cookie
scp /var/lib/rabbitmq/.erlang.cookie root@rabbitmq-2:/var/lib/rabbitmq/.erlang.cookie
scp /var/lib/rabbitmq/.erlang.cookie root@rabbitmq-3:/var/lib/rabbitmq/.erlang.cookie
chmod 600 /var/lib/rabbitmq/.erlang.cookie
3.重启
systemctl restart rabbitmq-server.service
- 加入集群
节点2执行
rabbitmqctl stop_app
rabbitmqctl join_cluster rabbit@rabbitmq-1
rabbitmqctl start_app
节点3执行
rabbitmqctl stop_app
rabbitmqctl join_cluster rabbit@rabbitmq-1
rabbitmqctl start_app
同步策略，任意一台均可
rabbitmqctl set_policy ha-all "^." '{"ha-mode":"all"}'
- 查询集群状态
rabbitmqctl cluster_status
- 管理用户
rabbitmqctl add_user admin StrongPassword
rabbitmqctl set_user_tags admin administrator # 修改用户角色
rabbitmqctl set_permissions -p / admin ".*" ".*" ".*" # 修改用户权限
9. web 控制台
启动RabbitMQ Web 控制台
rabbitmq-plugins enable rabbitmq_management
关闭RabbitMQ Web 控制台
rabbitmq-plugins disable rabbitmq_management
二、集群
https://www.rabbitmq.com/docs/clustering # 最新版本
https://v3-12.rabbitmq.com/documentation.html # 3.12版本
rabbitmq集群大概有五种方案：
1.普通集群
-- 内容只存在其声明节点上。其他节点只存储元数据（如队列名称、绑定关系等）。当客户端连接到非队列所在节点并执行诸如消费消息的操作时，该节点会作为代理，将请求转发给实际持有队列的节点
优点：资源利用效率高，因为消息不会被复制到所有节点。
缺点：如果持有队列的节点宕机，该队列将不可用，直到节点恢复。
2.镜像集群(Quorum mirroring)
-- 有一个主副本（master）和多个从副本（slave）。所有对队列的操作都首先在主副本上执行，然后异步复制到从副本。
-- RabbitMQ 3.9 被弃用（4.0被完全启用），并建议使用Quorum队列和Streams作为替代
优点：提高了可用性，因为如果主副本所在的节点失效，最老的从副本会被提升为新的主副本。
缺点：
增加了网络带宽和磁盘空间的使用，因为每个消息都被复制到所有镜像。
写入吞吐量可能下降，因为每个操作都需要被复制。
在网络分区的情况下可能导致脑裂或数据丢失。
3.Quorum(仲裁)队列
-- 3.8中引入，旨在克服镜像队列的一些问题。基于Raft共识算法，提供一致性保证。队列数据在奇数个节点（通常是3或5）之间复制。只要大多数节点（即quorum）可用，队列就能继续工作
优点：
更好的故障处理：能更优雅地处理网络分区，减少数据丢失的风险。
显式的故障转移：不像镜像队列中的隐式故障转移，Quorum队列中的leader选举是明确的。
没有脑裂问题：由于使用了共识算法，即使在网络分区的情况下也能保证数据一致性。
缺点：
由于需要在多数节点上达成一致，可能比镜像队列稍慢一些。
不支持一些高级特性，如优先级队列、消息TTL等。
4.Streams集群模式(高可用+负载均衡)
-- 3.9+ 最新引入的一种新型数据结构，借鉴了Apache Kafka的一些理念。消息以追加日志的形式存储，支持多消费者订阅，每个消费者维护自己的消费位置。
-- 流由领导者和副本Erlang进程组成，分布在RabbitMQ集群的节点上
-- 发布应用程序可以连接到任何节点，消息会自动转发到领导者进程所在的节点。而消费应用程序必须连接到包含流成员的节点，以利用sendfile优化
优点：
持久化开销小，非常适合需要长期存储大量消息的场景。
支持消息重放，消费者可以从任意位置开始消费。
集群复制基于Raft算法，提供了类似Quorum队列的一致性保证。
5.插件方式
-- Shovel Plugin 主要实现消息从一个 RabbitMQ集群（或单个节点）到另一个 RabbitMQ集群传输。通常用于地理上分散集群间传递消息，或要跨数据中心传递消息时使用。
-- Federation Plugin 允许 RabbitMQ集群间动态消息共享。在不进行消息物理传输的情况下，可以在多个 RabbitMQ 集群之间共享消息流，通常用于构建更松散耦合的集群架构。
目前推荐使用的集群模式就是Quorum队列与Streams。
Quorum队列支持高可用，而Streams模式即支持高可用集群又支持负载均衡集群。Quorum队列模式也可以借助HAproxy来支持负载均衡。