8K字详解：RabbitMQ基础概念和编程模型

MQ介绍

MQ：MessageQueue，消息队列。 队列，是一种FIFO 先进先出的数据结构。消息由生产者发送到MQ进行排队，然后按原来的顺序交由消息的消费者进行处理

MQ的作用主要有以下三个方面：

• 异步：提高系统响应速度和吞吐量；（快递员放快递到菜鸟驿站，客户有时间再取）
• 解耦：减小服务间影响（提高稳定性），实现数据分发（发布/订阅模式，一个生产者对应多个消费者）
• 削峰：稳定的系统资源应对突发的流量冲击（防止突发流量造成服务宕机）

MQ优缺点

• 系统可用性降低（外部依赖增多，一旦MQ宕机，会对业务产生影响）
• 系统复杂性提高（同步变异步，引入消息消费问题，消息不丢失，顺序消费，重复消费等）
• 消息一致性问题（多个消费者如何保证同时成功/失败）

常用的MQ产品包括Kafka、RabbitMQ和RocketMQ

RabbitMQ安装

Releases · rabbitmq/erlang-rpm (github.com)下载地址

bash

复制代码

rpm -ivh rabbitmq-server-3.9.15-1.el7.noarch.rpm # 启动服务，后台进程 service rabbitmq-server start # 启动程序，前台运行，查看启动过程 rabbitmqctl start_app # 状态 service rabbitmq-server status # 关闭服务 rabbitmqctl stop_app

安装web控制台插件,重启后生效

shell

复制代码

rabbitmq-plugins enable rabbitmq_management http://192.168.119.133:15672 创建管理员用户 rabbitmqctl add_user admin admin rabbitmqctl set_user_tags admin administrator

集群搭建

普通模式

在这种集群模式下，集群各节点之间只会有相同的元数据，而消息不会冗余，只存在一个节点，消费者在消费时，请求到了没有该消息的节点，RabbitMQ会临时在节点间进行数据传输。

这种模式下消息可靠性不高。也不支持高可用，某一个节点挂了之后，需要重启服务后，才能让这个节点的消息正常消费。

镜像模式

RabbitMQ的官方HA高可用方案。需要在搭建了普通集群之后再补充搭建。其本质区别在于，这种模式会在镜像节点中间主动进行消息同步，而不是在客户端拉取消息时临时同步。

并且在集群内部有一个算法会选举产生master和slave，当一个master挂了后，也会自动选出一个来。从而给整个集群提供高可用能力。

这种模式的消息可靠性更高，因为每个节点上都存着全量的消息。而他的弊端也是明显的，集群内部的网络带宽会被这种同步通讯大量的消耗，进而降低整个集群的性能。这种模式下，队列数量最好不要过多。

1、同步集群节点的cookie,路径/var/lib/rabbitmq/.erlang.cookie

2、将worker1和worker3加入worker2的集群中rabbitmqctl join_cluster --ram rabbit@worker2 加入时首先要启动worker1和worker3上的服务，否则出现如下错误

sql

复制代码

NODENAME=rabbit@worker3 依次执行 service rabbitmq-server start rabbitmqctl start_app rabbitmqctl join_cluster --ram rabbit@worker2

加入集群后如下所示，rabbitmqctl cluster_status查看集群状态

--ram，表示节点的元数据（交换机、队列定义信息）只保存在内存中；此时存在单点故障，如果worker2节点宕机，元数据有可能丢失。所以官方不建议所有节点都使用ram。

---

通常在生产环境中，为了减少RabbitMQ集群之间的数据传输，在配置镜像策略时，会针对固定的虚拟主机virtual host来配置。

创建一个虚拟主机，并添加对应的镜像策略

json

复制代码

rabbitmqctl add_vhost /mirror rabbitmqctl set_policy ha-all --vhost "/mirror" "^" '{"ha-mode":"all"}'

通常镜像模式的集群已经足够满足大部