RabbitMQ 详解——RabbitMQ 架构部署（四）

RabbitMQ 服务端搭建(RabbitMQ 3.9.8)

单一模式

单一模式就是单节点模式，不具备可靠性和高可用性

安装(docker 方式)

#拉取最新的镜像

docker pull rabbitmq:management

查看本地镜像

docker images

创建并运行 rabbitmq 镜像

docker run -di --hostname rabbit1 --name='myrabbit1' -p 15673:15672 -p 5673:5672 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie' -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin rabbitmq:management

普通集群模式

RabbitMQ 的集群模式通过增加多个节点缓解单个节点的服务和资源压力，做到可以横向扩展。RabbitMQ 默认集群模式并不保证队列的高可用性，尽管交换机、绑定这些可以复制到集群里的任何一个节点，但是队列内容不会复制。他的消费机制：对于消费者来说，若消息进入 A 节点的队列中，当从 B 节点拉取时，rabbit 会将消息从 A 中取出，并经过 B 发送给消费者。虽然该模式解决一项目组节点压力，但队列节点宕机直接导致该队列无法应用，只能等待重启

安装（接上文的单一模式增加两个节点）

docker run -di --hostname rabbit2 --name myrabbit2 -p 15674:15672 -p 5674:5672 --link myrabbit1:rabbit1 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie' -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin rabbitmq:management

docker run -di --hostname rabbit3 --name myrabbit3 -p 15675:15672 -p 5675:5672 --link myrabbit1:rabbit1 --link myrabbit2:rabbit2 -e RABBITMQ_ERLANG_COOKIE='rabbitcookie' -e RABBITMQ_DEFAULT_USER=admin -e RABBITMQ_DEFAULT_PASS=admin rabbitmq:management

集群必须有相同的 erlang 的 cookie 在 RabbitMQ 集群集群中，必须至少有一个磁盘节点，否则队列元数据无法写入到集群中，当磁盘节点宕掉时，集群将无法写入新的队列元数据信息查看容器

docker ps|grep rabbit

以第一个节点 rabbit1 作为主节点，把 rabbit2 和 rabbit3 加入到 rabbit1 进入 rabbit1 容器

docker exec -ti 0df1da7318d4 bash# 依次执行命令# 停止服务rabbitmqctl stop_app# 离开所在的集群rabbitmqctl reset# 启动服务rabbitmqctl start_app# 退出容器exit

进入 rabbit2 容器

docker exec -ti c991ded3668b bash# 依次执行命令# 停止服务rabbitmqctl stop_app# 离开所在的集群rabbitmqctl reset# 加入集群rabbitmqctl join_cluster rabbit@rabbit1# 启动服务rabbitmqctl start_app# 退出容器exit

进入 rabbi3 容器

docker exec -ti efbd7557a264 bash# 依次执行命令# 停止服务rabbitmqctl stop_app# 离开所在的集群rabbitmqctl reset# 加入集群,ram参数表示内存节点,默认磁盘节点(disc)rabbitmqctl join_cluster --ram rabbit@rabbit1# 启动服务rabbitmqctl start_app# 退出容器exit

进入任何一个节点下查看集群信息

rabbitmqctl cluster_status

至此,rabbitmq 的普通集群已经搭建好了,可以很好的提升性能

消息生产消费执行时序

集群中各节点有相同的队列结构，但消息只会存在于集群中的一个节点。对于消费者来说，若消息进入 A 节点的队列中，当从 B 节点拉取时，rabbit 会将消息从 A 中取出，并经过 B 发送给消费者

主备模式

• 主备模式，也称之为 Warren 模式，即主节点如果挂了，切换到从节点继续提供服务

• 主备模式的简单架构模型，主要是利用 HaProxy 去做的主备切换，当主节点挂掉时，HaProxy 会自动进行切换，把备份节点升级为主节点

• 
  

镜像集群模式

集群模式虽然可以提升服务端的性能，但是高可用还差一点,主节点挂了话,整个集群都不能使用了，单个节点宕机会导致部分节点不可用,所以要想真正高可用,还需扩展为镜像模式的集群，集群模式就是，就要复制队列内容到集群里的每个节点，所以必须要创建镜像队列进入主节点的容器,执行命令,将所有 queue 都进行镜像(配置不同参数可以选择 queue)

配置

• 方式一

rabbitmqctl set_policy ha-all "^" '{"ha-mode":"all"}'

• 方式二通过界面进行配置

消息生产消费执行时序

镜像队列设置后，会分一个主节点和多个从节点，如果主节点宕机，从节点会有一个选为主节点，原先的主节点起来后会变为从节点。queue 和 message 虽然会存在所有镜像队列中，但客户端读取时不同的节点都会把请求转到内部选取出来的主节点，然后主节点再将 queue 和 message 的状态同步给从节点，因此多个客户端连接不同的镜像队列不会产生同一 message 被多次接受的情况

主节点的查看方式

远程集群模式（Shovel）

远程模式是一个可以实现双活的一种模式，简称 Shovel 模式，所谓 Shovel 就是我们可以把消息进行不同数据中心的复制工作，我们可以跨地域的让两个 MQ 集群互连，下文介绍常用的多活架构模式（federation）,所以本集群模式不做实践

多活模式（Federation）

Shovel 远程模式其实就是将 RabbitMQ Server 根据不同的地域，部署到了不同的地域位置，从而实现对 RabbitMQ Server 的远程调用，但是，这种远程调用方式配置起来过于繁琐，会花费很长的时间，这有点得不偿失。所以，RabbitMQ 官方考虑到了这一弊端，才会有今天的 Federation 多活集群模式

部署架构

部署

基于前文，我们使用 rabbit4 和 rabbit5 两台机器做 federation 模式的实践实现从 rabbit5 往 rabbit4 上同步

• 需要安装 federation 的插件

rabbitmq-plugins enable rabbitmq_federation
rabbitmq-plugins enable rabbitmq_federation_management

• 一般我们不用 admin 做同步的用户，所以我们单独创建 federation 不通的用户，在两个 rabbitmq 节点上分别创建用户创建用户 ：fed_test 指定 tag：administrator 同时我们创建两个不同的 vhost

• vhost 绑置用户权限

• 在 rabbit4 和 rabbit5 上配置需要交换的交换机

• 在 rabbit4 和 rabbit5 上配置交换的队列同时绑定到交换机上

• 在 rabbit4 上配置 upstream

URI 配置格式

amqp://fed_user[用户名]:fed_user[密码]@172.168.1.36:5677 [拉取的上游地址]

• rabbit4 上添加 policy

• 配置成功后在 rabbit4 上会看到如下的同步状态

• 在上游的机器队列中会看到对了 （同时消息可以同步过来）,也可以配置双向的同步

负载均衡策略

bbitMQ 自身没有负载均衡的能力，所以要结合其他的中间件做负载均衡和故障转移这样的能力做到消息服务的最终的高可用，可以在一些客户端层面去做，也可以使用一些提供负载均衡能力的中间件去完成这样的工作，目前大部分公司使用的方案是 Haproxy+KeepAlived 的方案，本文也主要介绍这种方案的环境搭建

执行时序

• 当我们的应用程序，或者生产者需要使用我们的 RabbitMQ Server 时，就会向我们的 RabbitMQ Server 发送请求，由图可知，该请求会被我们所配置的负载均衡策略所截获，同时，负载均衡策略会根据请求的内容，来将请求分发到相应的地域节点中的 RabbitMQ Server 中。

• Federation 多活集群模式与 Shovel 远程调用集群模式最大的不同之处在于，Shovel 远程调用集群模式需要指定主区域，即可以理解为主节点，但是 Federation 多活集群模式不需要指定，它的每一个节点都相当于是主节点，每一个节点都是活跃的， 请求只会根据不同的负载均衡策略来分发到不同的地域节点上而已

HA 安装部署

KeepAlived的安装部署

RabbitMQ 高可用集群架构图