赞
踩
单机版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
vim /etc/hostname
vim /etc/hosts
192.168.3.114 node1
192.168.3.115 node2
192.168.3.116 node3
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
docker-compose up -d
#查看rabbitmq是否启动成功
docker ps
#查看rabbitmq启动日志,如果报错通过查看日志解决问题
docker logs -f -t 容器id
访问三台rabbitmq的管理界面,都能访问说明启动正常
如果不能访问,关闭服务器的防火墙,查看rabbitmq启动日志,看是否报错
rabbitmqctl stop_app
rabbitmqctl reset
rabbitmqctl join_cluster rabbit@node1
rabbitmqctl start_app(只启动应用服务)
再次访问rabbitmq管理界面
此时node2加入进群。
node3同理 按照 相同操作
/var/lib/rabbitmq/.erlang.cookie:/var/lib/rabbitmq/.erlang.cookie
vim /var/lib/.erlang.cookie
的值rabbitmqctl cluster_status
如果 RabbitMQ 集群中只有一个 Broker 节点,那么该节点的失效将导致整体服务的临时性不可用,并
且也可能会导致消息的丢失。可以将所有消息都设置为持久化,并且对应队列的durable属性也设置为true,
但是这样仍然无法避免由于缓存导致的问题:因为消息在发送之后和被写入磁盘井执行刷盘动作之间存在
一个短暂却会产生问题的时间窗。通过 publisherconfirm 机制能够确保客户端知道哪些消息己经存入磁盘,
尽管如此,一般不希望遇到因单点故障导致的服务不可用。
引入镜像队列(Mirror Queue)的机制,可以将队列镜像到集群中的其他 Broker 节点之上,如果集群中
的一个节点失效了,队列能自动地切换到镜像中的另一个节点上以保证服务的可用性。
未使用镜像队列时
查看node1节点的队列
查看node2节点的队列
显示的队列都是node1的队列,如果此时node1宕机了,再次查看 node2的队列
发现队列处于down的状态,此时队列不可用,因此我们需要创建镜像队列让队列进行备份。
创建镜像队列
在任意一个节点的管理界面上配置相关策略
本次案例中的正则表达式为[a-z]*
添加策略后再次查看管理界面
说明此时队列成为镜像队列
查看队列具体详情
可以看到队列主节点为node1 备份在node3 如果此时主节点宕机
node3为主节点 node2备份
就算整个集群只剩下一台机器了 依然能消费队列里面的消息
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。