消息中间件—RabbitMQ(四)集群

一、集群目的

为了解决高可用和负载问题。

二、集群节点类型

节点分为内存节点和磁盘节点,磁盘节点用来做持久化,内存节点做应用访问。
集群的互相通信端口为25672。

三、集群类型

1、普通集群

普通集群中,只有一个节点会存储一个队列的全部消息,其他节点将只存储该队列的元数据,当有请求发送至其他节点时,其他节点将把消息转发过去,向存储消息的节点继续请求,以此获得消息。

  • 优点:效率很高,不需要在发生写操作时将数据同步给全部节点
  • 缺点:可靠性不足,一旦存储队列消息的节点崩溃,其他节点也就永远失去了这部分消息。
    在这里插入图片描述

2、镜像队列

镜像队列中,所有的节点都会存储所有队列的元数据与消息,此做法的优缺点和普通集群刚好相反。

在这里插入图片描述

四、负载均衡

当有多个主机节点需要选择时,需要负载均衡选择连接哪一个节点,但负载均衡只单机运行是不够的,因为一旦这个负载均衡挂掉,就无法对任何节点提供连接,那么只能集群部署负载均衡,但是集群部署的负载均衡也无法决定到底连接哪一个节点,于是又回到了第一个问题,陷入死循环。好在HAProxy为我们提供了一个解决方案。
在如下的结构图中,应用访问一个固定的IP地址,Keepalived的集群将会竞争这个IP,竞争到IP的Keepalived就会和应用连接,同时Keepalived和HAProxy保持心跳连接,HAProxy做负载均衡,可以和任意一个RabbitMQ的内存节点进行连接,注意,HAProxy不一定非要和RabbitMQ节点部署在同一台服务器上,分开部署也是可以的。最后,应用节点与磁盘节点有镜像复制数据,实现持久化。

在这里插入图片描述

五、一些情况

1、如何追溯消息的发送

可以增加一张消息表,以此来对所有的消息进行记录和重发。

2、消息全流程追踪

FireHose和Tracing GUI功能可以实现消息的全流程追踪,

3、大量消息发送

在通常情况下,一条消息发送一次就够了,但大量的消息发送会导致连接数过多,这时可以考虑批量发送消息,比如将多条消息拼接,然后一次性发送,减少连接数消耗。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值