docker+rabbitmq+HAproxy 部署 镜像模式 的集群
为了解决上篇文章中 的 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然后运行 启动命令
haproxy -f ./haproxy.cfg查看运行状况;如果有执行结果 表示 没问题,有 ALERT 可以忽略
ps -ef | grep haproxyWEB页面查看效果图:
3.简单测试 此模式
ONE: 客户端代码 全部通过 5672端口访问 rabbitmq集群服务, 1个客户端生产者连接,3个客户端消费者连接,然后 生产者 发送一条消息, 查看消费者 是否 重复消费; 结论 没有重复消费
TWO: 上述操作后, 关闭 某节点服务,查看 3个消费者 连接是否 正常,以及HAproxy,Rabbitmq 的 web 界面是否出现对应 失效的节点; 结论:消费者会突然报错然后从新连接成功, web界面会出现对应失效节点信息;
注意点:
主节点(被复制 .erlang.cookie文件) 宕机后 其他节点 照常提供服务(队列 如果在主节点,这时会 在其他节点新建);
在 所有节点 都宕机后 重启 每个节点的rabbitmq服务时,必须先启动 主节点(被复制 .erlang.cookie文件)的rabbitmq服务,在启动其他节点的rabbitmq服务,否则 会启动失败;
为了 更好的 应用 镜像模式 最好 理解一下 磁盘节点和内存节点的区别 , 然后得到如下 总结:
在 镜像模式中, 某些 非至关重要的 队列需求中,可以将 队列的 生产者 消费者 设置为 非持久化,再加上 好几个节点 进行容错, 在 只要不是狗屎运的情况下(所有节点都同时宕机),应该能 得到 很好的 消息存取速率,和保证消息不丢失(高可用);
在 使用 HAproxy时 可以通过 mailers 发送相关邮件(注意HAproxy版本),只是 要 本地服务器实现 发送邮件功能,不能输入 邮箱号,密码等 使用第三方邮件服务(如qq),可以通过 mailx 间接使用第三方邮件服务器 发送邮件(ubuntu系统mailx很难成功);
在 使用 HAproxy时 可以使用 externel-check选项 增加额外的脚本 进行 服务 健康检查;
相关连接:
HAproxy添加日志输出到文件
2.0.1版本 HAproxy centos系统编译安装
https://www.rabbitmq.com/clustering.html
https://www.cnblogs.com/flat_peach/archive/2013/04/07/3004008.html#commentform