导航
导航
文章目录
  1. Rabbitmq默认的集群模式
  2. RabbitMQ镜像队列模式

rabbitmq集群原理

2022.02.25 sherryriver 流水账技术  pv:

RabbitMQ本身是基于Erlang编写，Erlang语言天生具备分布式特性（通过同步Erlang集群各节点的erlang.cookie来实现）。因此，RabbitMQ天然支持集群。

Rabbitmq默认的集群模式

RabbitMQ集群会始终同步四种类型的内部元数据：

  1. 队列元数据：队列名称和它的属性
  2. 交换器元数据：交换器名称、类型和属性
  3. 绑定元数据：一张简单的表格展示了如何将消息路由到队列
  4. vhost元数据：为vhost内的队列、交换器和绑定提供命名空间和安全属性

因此，当用户访问其中任何一个RabbitMQ节点时，通过rabbitmqctl查询到的queue／user／exchange/vhost等信息都是相同的

RabbitMQ集群仅采用元数据同步的方式一方面是节省存储空间，不需要copy完全数据。二来提高性能

默认集群模式，并不保证队列的高可用性。尽管交换机、绑定这些可以复制到集群里的任何一个节点，但是队列内容不会复制。虽然该模式解决一项目组节点压力，但队列节点宕机直接导致该队列无法应用，只能等待重启。所以要想在队列节点宕机或故障也能正常应用，就要复制队列内容到集群里的每个节点，必须要创建镜像队列。

RabbitMQ镜像队列模式

镜像队列是基于普通的集群模式的。

镜像队列基本上就是一个特殊的BackingQueue，它内部包裹了一个普通的BackingQueue做本地消息持久化处理，在此基础上增加了将消息和ack复制到所有镜像的功能。所有对mirror_queue_master的操作，会通过可靠组播GM的方式同步到各slave节点。GM负责消息的广播，mirror_queue_slave负责回调处理，而master上的回调处理是由coordinator负责完成。mirror_queue_slave中包含了普通的BackingQueue进行消息的存储，master节点中BackingQueue包含在mirror_queue_master中由AMQQueue进行调用。 消息的发布（除了Basic.Publish之外）与消费都是通过master节点完成。master节点对消息进行处理的同时将消息的处理动作通过GM广播给所有的slave节点，slave节点的GM收到消息后，通过回调交由mirror_queue_slave进行实际的处理。 对于Basic.Publish，消息同时发送到master和所有slave上，如果此时master宕掉了，消息还发送slave上，这样当slave提升为master的时候消息也不会丢失。

GM模块实现的一种可靠的组播通讯协议，该协议能够保证组播消息的原子性，即保证组中活着的节点要么都收到消息要么都收不到。 它的实现大致如下： 将所有的节点形成一个循环链表，每个节点都会监控位于自己左右两边的节点，当有节点新增时，相邻的节点保证当前广播的消息会复制到新的节点上；当有节点失效时，相邻的节点会接管保证本次广播的消息会复制到所有的节点。在master节点和slave节点上的这些gm形成一个group，group（gm_group）的信息会记录在mnesia中。不同的镜像队列形成不同的group。消息从master节点对于的gm发出后，顺着链表依次传送到所有的节点，由于所有节点组成一个循环链表，master节点对应的gm最终会收到自己发送的消息，这个时候master节点就知道消息已经复制到所有的slave节点了。

镜像队列属于HA方案。该模式解决了普通模式中的问题，根本区别在于消息实体会主动在镜像节点间同步，而不是在客户端拉取数据时临时拉取。当然弊端就是降低系统性能，大量消息写入。但是镜像队列不能作为负载均衡使用，因为每个操作在所有节点都要操作一遍。为了实现RabbitMQ集群的软负载均衡，可以选择HAProxy。Haproxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机。Keepalived的作用是检测web服务器的状态，如果有一台web服务器死机，或工作出现故障，Keepalived将检测到，并将有故障的web服务器从系统中剔除，当web服务器工作正常后Keepalived自动将web服务器加入到服务器群中。