为了解决上篇文章中 的  docker+rabbitmq 部署 普通模式 的集群  问题,此次通过  docker+rabbitmq+HAproxy部署 镜像模式的集群;

 

镜像模式介绍

镜像模式 实现了 队列的高可用, 因为 客户端生产的 队列任务数据 会 立刻主动的 复制到 集群中的所有节点上;这样 保证 任何一个节点宕机后,其他节点保证在不丢失数据的情况下 继续提供服务;从而实现高可用;(在默认集群模式基础上 增加了 同步队列数据的功能)

节点间同步数据机制: 不必担心同步数据丢失问题,因为 主节点接收数据后 会立刻同步到每个可用节点中,只有所有节点都同步成功 才 返回给客户端 表示 上传消息成功的 通知;不会出现mysql主从 异步或同步 数据丢失的问题;

 

HAproxy介绍

HAproxy:是一款提供高可用性、负载均衡以及基于TCP和HTTP应用的代理软件, HAproxy是完全免费的、借助 HAproxy可以快速并且可靠的提供基于TCP和HTTP应用的代理解决方案,HAproxy适用于那些负载较大的web站点,这些站点通常又需要会话保持或七层处理。HAproxy可以支持数以万计的并发连接,并且 HAproxy的运行模式使得它可以很简单安全的整合进架构中,同时可以保护web服务器不被暴露到网络上;实现了负载均衡 和反向代理;

和其他web服务器的比较

相同点：在功能上，HAproxy通过反向代理方式实现 WEB均衡负载。和 Nginx，ApacheProxy，lighttpd，Cheroke 等一样。
不同点：Haproxy 并不是 web 服务器。以上提到所有带反向代理均衡负载的产品，都清一色是 WEB 服务器。简单说，就是他们能处理解析页面的。而Haproxy 仅仅是一款的用于均衡负载的应用代理。其自身并不能提供web服务。但其配置简单，拥有非常不错的服务器健康检查功能还有专门的系统状态监控页面，当其代理的后端服务器出现故障, HAProxy会自动将该服务器摘除，故障恢复后再自动将该服务器加入。

 

rabbitmq集群 为何引入 HAproxy?

在 客户 连接 rabbitmq集群时,如果没有 HAproxy,则 客户端 必须连接每个节点,保证 每个节点 负载尽量相同,并且在 某个节点宕机时 对应连接的 客户端 还要手动的 修改连接的 节点, 因为这些缺点 导致 必须因为 HAproxy;

 

docker+rabbitmq部署 镜像集群步骤

部署架构图:

节点信息(部署 时 会用到):

内网IP        hostname     容器ID  web端口   节点类型 
172.30.0.3 6e3c19a1cd23 rabbit_1 15673   disk(磁盘)   此节点为 主节点
172.30.0.2 cb959d1f3550 rabbit_2 15674   ram(内存)
172.30.0.5 16e7cb4bcfff rabbit_3 15675   ram(内存)

由于 镜像模式+ HAproxy 部署 是在  默认集群模式基础上 添加的功能,因此 要先 实现 默认集群镜像模式的部署,请点击链接

1.设置镜像策略

在任何一个集群节点(rabbitmq_1,rabbitmq_2,rabbitmq_3)上执行如下命令:  

rabbitmqctl set_policy -p / ha-all "^" '{"ha-mode":"all"}'    # 给 vhost 为/ 策略名为 ha_all 的所有节点 进行镜像复制

set_policy原文链接

然后 打开集群节点 的 某个 WEB 界面 查看队列页面如下:

 

结论: 说明  持久化 和 节点存储类型无关,所以不存在 内存节点 比磁盘节点 存取数据 效率更高的情况;

 

2.设置 HAproxy

在 rabbitmq_4节点上 设置HAproxy

进入容器 输入如下命令

docker exec -it rabbitmq_1 /bin/bash

停止 rabbitmq服务(此节点 只 做 HAproxy)

rabbitmqctl stop

进入到  /etc/haproxy目录

编写 haproxy.cfg文件

global
	log /dev/log	local0
	log /dev/log	local1 notice
	chroot /var/lib/haproxy
	stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
	stats timeout 30s
	user haproxy
	group haproxy
	daemon

	# Default SSL material locations
	ca-base /etc/ssl/certs
	crt-base /etc/ssl/private

	# Default ciphers to use on SSL-enabled listening sockets.
	# For more information, see ciphers(1SSL). This list is from:
	#  https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers/
	# An alternative list with additional directives can be obtained from
	#  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
	ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
	ssl-default-bind-options no-sslv3

defaults
	log	global
	mode	http
	option	tcplog
	option	dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
	errorfile 400 /etc/haproxy/errors/400.http
	errorfile 403 /etc/haproxy/errors/403.http
	errorfile 408 /etc/haproxy/errors/408.http
	errorfile 500 /etc/haproxy/errors/500.http
	errorfile 502 /etc/haproxy/errors/502.http
	errorfile 503 /etc/haproxy/errors/503.http
	errorfile 504 /etc/haproxy/errors/504.http

# 对接 客户端
frontend Rabbitmq_frontend
    # 客户端连接地址
	bind 0.0.0.0:5672
	# tcp连接
	mode tcp
	option clitcpka
	timeout client 100m
	maxconn 10000
	# 对应 后端 集群
	default_backend Rabbitmq_Backend

backend Rabbitmq_Backend
	mode tcp
	timeout queue 100m
	timeout server 300m
	option srvtcpka
	option redispatch
	fullconn 10000
	# 负载均衡策略
	balance roundrobin
	option tcp-check
	# 添加节点
	#       主机hostname rabbitmq服务url  权重
	server 6e3c19a1cd23 172.30.0.3:5672 weight 3 maxconn 1000 check port 5672 inter 5000 rise 2 fall 2
	server cb959d1f3550 172.30.0.2:5672 weight 3 maxconn 1000 check port 5672 inter 5000 rise 2 fall 2
	server 16e7cb4bcfff 172.30.0.5:5672 weight 3 maxconn 1000 check port 5672 inter 5000 rise 2 fall 2


listen stats
    # web页面访问url
	bind 0.0.0.0:8100
	mode http
	option httplog
	stats enable
	# 添加 的 路由 为 /rabbit  所有 访问 url为: http://0.0.0.0:8100/rabbit
	stats uri /rabbit
	# 5s刷新一下 数据
	stats refresh 5s
	# 登录认证 用户名:密码
	stats auth root:root

# 启动命令为:haproxy -f ./haproxy.cfg

然后执行如下 命令 生成 haproxy需要的文件夹

mkdir /run/haproxy

然后运行 启动命令

mkdir /run/haproxy

查看运行状况;如果有执行结果 表示 没问题,有 ALERT 可以忽略

ps -ef | grep haproxy

WEB页面查看效果图:

3.简单测试 此模式

    ONE: 客户端代码 全部通过  5672端口访问 rabbitmq集群服务, 1个客户端生产者连接,3个客户端消费者连接,然后 生产者 发送一条消息, 查看消费者 是否 重复消费; 结论 没有重复消费

     TWO: 上述操作后, 关闭 某节点服务,查看 3个消费者 连接是否 正常,以及HAproxy,Rabbitmq 的 web 界面是否出现对应 失效的节点;   结论:消费者会突然报错然后从新连接成功, web界面会出现对应失效节点信息;

 

注意点:

主节点(被复制 .erlang.cookie文件) 宕机后 其他节点 照常提供服务(队列 如果在主节点,这时会 在其他节点新建);

在 所有节点 都宕机后 重启 每个节点的rabbitmq服务时,必须先启动 主节点(被复制 .erlang.cookie文件)的rabbitmq服务,在启动其他节点的rabbitmq服务,否则 会启动失败;

为了 更好的 应用 镜像模式 最好  理解一下  磁盘节点和内存节点的区别 , 然后得到如下 总结:

在 镜像模式中, 某些 非至关重要的 队列需求中,可以将 队列的 生产者 消费者 设置为 非持久化,再加上 好几个节点 进行容错, 在 只要不是狗屎运的情况下(所有节点都同时宕机),应该能 得到 很好的 消息存取速率,和保证消息不丢失(高可用);

 

相关连接:

https://www.rabbitmq.com/clustering.html

https://www.cnblogs.com/flat_peach/archive/2013/04/07/3004008.html#commentform