rabbitmq集群搭建

单机版rabbitmq，无法满足目前真实应用的要求。如果 RabbitMQ 服务器遇到内存崩溃、机器掉电或者主板故障等情况，该怎么办？单台 RabbitMQ服务器可以满足每秒 1000 条消息的吞吐量，那么如果应用需要 RabbitMQ 服务满足每秒 10 万条消息的吞
吐量呢？购买昂贵的服务器来增强单机 RabbitMQ 务的性能显得捉襟见肘，搭建一个 RabbitMQ 集群才是解决实际问题的关键。
集群搭建
本次搭建三台服务器分别为：192.168.3.114、192.168.3.115、192.168.3.116
对应为node1、node2、node3
本次集群采用dockercompose搭建，首先搭建docker环境，在搭建dockercompose

• 修改 3 台机器的主机名称

vim /etc/hostname

• 配置各个节点的 hosts 文件，让各个节点都能互相识别对方

vim /etc/hosts

192.168.3.114 node1
192.168.3.115 node2
192.168.3.116 node3

• 三台rabbitmq的docker-compose.yml 配置文件

version: '3'
services:
  rabbitmq:
    image: rabbitmq:management
    hostname: node1
    container_name: rabbitmq1
    restart: always
    environment:
      ERLANG-COOKIE: rabbitmqcluster
    ports:
     - "15672:15672"
     - "25672:25672"
     - "4369:4369"
     - "5671:5671"
     - "5672:5672"
    volumes:
     - /usr/local/rabbitmq/data:/var/lib/rabbitmq
     - /etc/hosts:/etc/hosts
     - /var/lib/rabbitmq/.erlang.cookie:/var/lib/rabbitmq/.erlang.cookie

第二台、第三台分别对应node2、node3；rabbitmq2、rabbitmq3

• 三台服务器启动rabbitmq

#启动rabbitmq
docker-compose up -d
#查看rabbitmq是否启动成功
docker ps
#查看rabbitmq启动日志，如果报错通过查看日志解决问题
docker logs -f -t 容器id

访问三台rabbitmq的管理界面，都能访问说明启动正常
如果不能访问，关闭服务器的防火墙，查看rabbitmq启动日志，看是否报错

• 将三台服务器加入集群
  以node1作为集群，将node2和node3分别加入node1
  首先进入node2节点的rabbitmq容器执行以下命令

rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node1
rabbitmqctl start_app(只启动应用服务)

再次访问rabbitmq管理界面

此时node2加入进群。
node3同理 按照 相同操作

• 加入集群错误信息
  在进去容器后执行join_cluster rabbit@node1报错
  
  根据提示信息：

1. 目标节点不可达(例如，由于主机名解析、TCP连接或防火墙问题)
   防火墙问题，主机无法识别，没有按照第一个步骤配置hostname和hosts文件
2. erlang的cookie不同
   必须保证集群三个节点的erlang.cookie相同。在配置docker容器卷的时候添加
   /var/lib/rabbitmq/.erlang.cookie:/var/lib/rabbitmq/.erlang.cookie
   如果三个节点的erlang.cookie不相同时，手动修改vim /var/lib/.erlang.cookie的值
   只要按照上面docker-compose.yml来配置就不会有问题
3. 集群节点未运行

• 进群信息查看
  随便进入一个rabbitmq容器 执行rabbitmqctl cluster_status
  
  到此集群搭建成功

镜像队列

如果 RabbitMQ 集群中只有一个 Broker 节点，那么该节点的失效将导致整体服务的临时性不可用，并
且也可能会导致消息的丢失。可以将所有消息都设置为持久化，并且对应队列的durable属性也设置为true，
但是这样仍然无法避免由于缓存导致的问题：因为消息在发送之后和被写入磁盘井执行刷盘动作之间存在
一个短暂却会产生问题的时间窗。通过 publisherconfirm 机制能够确保客户端知道哪些消息己经存入磁盘，
尽管如此，一般不希望遇到因单点故障导致的服务不可用。
引入镜像队列(Mirror Queue)的机制，可以将队列镜像到集群中的其他 Broker 节点之上，如果集群中
的一个节点失效了，队列能自动地切换到镜像中的另一个节点上以保证服务的可用性。

未使用镜像队列时
查看node1节点的队列

查看node2节点的队列

显示的队列都是node1的队列，如果此时node1宕机了，再次查看 node2的队列

发现队列处于down的状态，此时队列不可用，因此我们需要创建镜像队列让队列进行备份。

创建镜像队列
在任意一个节点的管理界面上配置相关策略

本次案例中的正则表达式为[a-z]*
添加策略后再次查看管理界面

说明此时队列成为镜像队列
查看队列具体详情

可以看到队列主节点为node1 备份在node3 如果此时主节点宕机

node3为主节点 node2备份
就算整个集群只剩下一台机器了 依然能消费队列里面的消息