rabbitmq高可用

admin管理员组

文章数量:1666598

rabbitmq高可用

2020年12月13日

19:30

 

rabbit集群+ 级联 + 镜像队列

 

1、多机多节点集群搭建

 

RabbitMQ集群中的所有节点都会备份所有的元数据信息，包括以下内容：

（1）队列元数据：队列的名称及属性

（2）交换器：交换器的名称及属性

（3）绑定关系元数据：交换器与队列或者交换器与交换器之间的绑定关系

（4）vhost元数据：为vhost内的队列、交换器和绑定提供命名空间以及安全属性

但是不会备份消息（镜像队列可以解决此问题）！集群中节点崩溃时，该节点消息会丢失。

 

Rabbitmq集群对延迟非常敏感，应当只在本地局域网内使用。在广域网中不应该使用集群，而应该使用Federation来代替。

 

搭建步骤：

（1）挂载、修改hosts文件

（2）编辑Rabbitmq的cookie,以确保各个节点的cookie文件使用的是同一个值。集群中的RabbitMQ节点需要通过交换秘钥令牌以获得相互认证。

（3）配置集群

从节点加入集群：

Rabbitmqctl stop_app

Rabbitmqctl reset

Rabbitmqctl join_cluster rabbit@center1

rabbitmqctl start_app

 

默认模式，以两个节点（rabbit01、rabbit02）为例来进行说明。对于Queue来说，消息实体只存在于其中一个节点rabbit01（或者rabbit02），rabbit01和rabbit02两个节点仅有相同的元数据，即队列的结构。当消息进入rabbit01节点的Queue后，consumer从rabbit02节点消费时，RabbitMQ会临时在rabbit01、rabbit02间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连rabbit01或rabbit02，出口总在rabbit01，会产生瓶颈。当rabbit01节点故障后，rabbit02节点无法取到rabbit01节点中还未消费的消息实体。如果做了消息持久化，那么得等rabbit01节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。

 

2、避免单点故障--镜像队列：

 

如果RabbitMQ集群中只有一个Broker节点，那么该节点的失效将导致整体服务的临时性不可用，并且也可能会导致消息的丢失。

引入镜像队列（Mirror Queue）的机制，可以将队列镜像到集群中的其它Broker节点之上，如果集群中的一个节点失效了，队列能自动切换到镜像中的另一个节点上以保证服务的可用性。

 

一主多从的架构，如果master由于某种原因失效，那么加入集群时间最长的那个slave会被提升为新的master。发送到镜像队列的所有消息会被同时发往master和所有的slave上，如果此时master挂掉了，消息还会在slave上。

 

如果消费者与slave建立连接并进行订阅消费，其实质上都是从master上获取消息，只不过看似是从slave上消费而已。master读写压力比较大，所以队列最好是均匀地散落在集群的各个broker节点中以达到负载均衡的目的。

 

镜像队列策略：

Pattern: queue的匹配模式（正则表达式）

 

ha-mode: 指明镜像队列的模式

ha-mode	ha-params	Desc
all	忽略	all表示镜像到集群上的所有节点，ha-params参数忽略
exactly	节点数量	表示在指定个数的节点上进行镜像，节点的个数由ha-params指定
nodes	节点列表	表示在指定的节点上进行镜像，节点名称通过ha-params指定

ha-sync-mode 参数设置

ha-sync-mode 参数是用来控制新加入集群群的镜像节点是否自动同步镜像队列中的消息；

默认情况下ha-sync-mode=manual ，表示镜像队列中的消息不会主动的同步到新节点，除非显式调用命令。当调用同步命令后，队列开始阻塞，无法对其进行操作，直到同步完成；

当 ha-sync-mode=automatic 时，新加入节点时会默认同步已知的镜像队列。同步过程中所有的消息都会被阻塞，直到同步完成。

ha-promote-on-shutdown 主节点选择参数配置

ha-promote-on-failure  故障转移参数配置

 

rabbitmq提供了ha-promote-on-shutdown，ha-promote-on-failure两个参数让用户决策是保证队列的可用性，还是保证队列的一致性；两个参数分别控制正常关闭、异常故障情况下mirror是否提升为master，其可设置的值为"when-synced"和"always"。

when-synced意味只有当slave与master完成数据同步了，才会被提升master；而always则意味着，无论什么情况slave都将被提升为master。

如同CAP理论只能满足其中两个，如果选择AP，即保证队列的可用性，可将两个参数均设置为"always"，如果选择CP，即保证队列消息的一致性，可将两个参数均设置为"when-synced"。

 

镜像队列的使用可以极大地提升RabbitMQ的可用性及可靠性，提供了数据冗余备份、避免单点故障的功能，强烈建议在实际应用中为每个重要的队列都配置镜像。

 

3、镜像队列原理：

所有对mirror_queue_master的操作，会通过组播GM的方式同步到各slave节点。GM负责消息的广播，mirror_queue_slave负责回调处理，而master上的回调处理是由coordinator负责完成。mirror_queue_slave中包含了普通的BackingQueue进行消息的存储，master节点中BackingQueue包含在mirror_queue_master中由AMQQueue进行调用。

GM, Guarenteed Multicast. GM模块实现的一种可靠的组播通讯协议，该协议能够保证组播消息的原子性，即保证组中活着的节点要么都收到消息要么都收不到。它的实现大致如下：

消息从master节点对于的gm发出后，顺着链表依次传送到所有的节点，所有节点组成一个循环链表，master节点对应的gm最终会收到自己发送的消息，这个时候master节点就知道消息已经复制到所有的slave节点了。

 

新节点加入过程如下：

 

 

 

4、跨越集群的界限--federation上下游

 

Federation使RabbitMQ在不同的broker节点之间进行消息传递而无需建立集群

（1）启用federation：

rabbitmq-plugins enable rabbitmq_federation rabbitmq_federation_management

 

（2）添加federation策略：

 

• • name：名字，可以使用任意 ASCII 字符，建议不要使用空格
  • pattern：用于匹配队列/交换机的正则表达式
  • definition：JSON格式的一组键值对，表示设置的属性，会被注入匹配队列/交换机
  • priority：优先级。一个队列/交换机只会有一个生效的 Policy，如果匹配多个 Policy，则优先级数值最大的 Policy 生效
  • apply-to：该 Policy 是针对队列，还是交换机，还是同时针对两者

 

（3）添加上游节点：

 

（4）查看上游节点状态

 

xiexie

本文标签： RabbitMQ