Skip to main content

Pywhio

官方 @ PywhiO. Python大数据, AI技术, 微服务, DRF+REACT前后端分离实践.

2 min read · March 22nd 2020 (originally published at pywhio)

RabbitMQ-Shovel的数据转移

阅读:-


RabbitMQ 是一种高可用的消息中间件。如果需要多个 RabbitMQ 进行级联的场景,我们就考虑会使用一个称为 Shovel 的插件来实现相关的功能。请大家参考一下相关的功能吧。

1 Shovel 介绍

Shovel 能够可靠、持续地从一个 Broker 中的队列(作为源端,即 source )拉取数据并转发至另一个 Broker 中的交换器(作为目的端,即 destination )。

作为源端的队列和作为目的端的交换器可以同时位于同一个 Broker 上,也可以位于不同的 Broker 上。

1584805025291

1.1 应用背景

消息中间件是分布方式计算环境下非常重要的一种中间件,可以非常方便的用于不同的组件之间进行解耦设计。这种设计模式,称为是生成者+消费者模式。 这种模式用于构建一般性的分布式应用的时候,基本上是没有问题的。 但是在一些超大型的分布式应用中,可能会存在的一些瓶颈,这些特殊的应用场景包括:

1.一套 rabbit-mq 中间件中存在很重的负载,很容易产生性能瓶颈。

2.生产者和消费者分布在不同的地理区域上,如果集中使用一套 rabbitmq,在地理上会存在消息迂回的问题。

3.在多中心的情况下,如果希望把 A 中心的负载,暂时迁移到 B 中心进行运行。

在上述场景下,一套 rabbitMQ 服务无法满足需求,这样就需要启用多套 rabbit MQ,在这种情况下。就需要利用到一个插件。

1584804813509

图 1 Rabbit –MQ 的消息传递插件

基于 rabbitmq 插件,我们就可以在不同的数据中心之间传递控制消息,实现弹性的扩展方案。

基于上述方案,一种典型的应用场景,见下图所显示。

1584804888051

 图 2 弹性扩展

从上图可见,如果为了获得一种更好的应用模式,还可以进一步进行弹性的扩展应用的规模。

2 Shovel 原理

1584804918322

如上图所示,通常情况下,使用 Shovel 时配置队列作为源端,交换器作为目的端。

2.1 RbbitMQ 单实例应用

RabbitMQ 是一个可靠的消息传递系统。他的基础原理阐述如下。

1,生产者将消息传送到 rabbitmq broker1 中,将首先到达一个 Exchange 的组件中。

1584805061459

2、Exchange 将根据传递消息中的 routing key, 将消息传递到对应的 Queue 中,在这个 Queue 中。

1584805076666

3、消费者将从和自己关联的 queue 中获取相关的消息。

1584805097188

2.2 RabbitMQ 多实例应用

假如随着业务规模的扩充,我们需要引入多个 RabbitMQ 的实例,此时我们需要将 message 从 1 个 queue 转移到另外一个 Queue 中去。

在这种情况下,如果不修改设计,将无法适配这种新的需求。这样会为项目的集成带来很大的困难。在这种情况下,应用插件 Rabbit MQ Shovel 将会帮忙你来克服这个困难。

1584805116904

图 3 集群应用环境

利用 shovel,我们可以非常方便的把所有存在的消息,从一个 queue 转移到另外的一个 queue 中去。

此外,任何新进入的消息,会转移到新的 consumer 处去。

1584805167142

图 4 Shovel 插件

2.3 引入 shovel 的价值

1.解除耦合。引入 shovel 以后,我们可以在不同的域 domain 中进行消息的转移。即使不同域(domain)中的主机,操作系统,甚至 RabbitMQ 的版本不一致,也不影响。

2.广域网友好。Shovel 具有 WAN-Friendly 的特性,他以客户端的形式和 borker 进行连接。相关的连接协议对于不稳定 intermittent 的连接环境进行了优化,可以保障消息不丢失。这也意味着,Shovel 可以像一个客户端一样工作,来连接到 Source broker 的 Queue 当中获取消息,同时连接到 Destination broker 中来发布消息到对应的 Queue 中去

3.客户化配置。Shovel 可以提供灵活的配置功能。我们可以提供两种模式的配置。

1584805200499

其中 Static shovels 是基于配置文件生成的,及时 rabbitMQ 发生了重启,也不会有影响。

而 Dynamic Shovels 是基于 Rabbit MQ 的控制台配置的,如果 Rabbit MQ 发生重启,则会影响。

3 Shovel 消息的转移测试

3.1 测试所需环境、配置参数

本次测试一共用到两台 linux 测试机,测试参数配置如下:

测试器 ubuntu16.04:

ip:192.168.223.132

测试机 ubuntu19.04

ip:192.168.223.134

两台测试机均以 docker 的方式部署了 rabbitmq 服务,其中 ubuntu16.04 作为本次测试的 source 主机,ubuntu19.04 作为本次测试的 destination 主机

3.2 测试流程

  1. Shovel 插件默认也在 RabbitMQ 的发布包中,首先执行docker exec -it ff8e1c651f82 /bin/bash 进入容器内部,然后执行命令:rabbitmq-plugins enable rabbitmq_shovel

rabbitmq-plugins enable rabbitmq_shovel_management

执行流程如下:

1584805319138

ubuntu16.04中执行此操作,执行完毕后, 在 RabbitMQ 的管理界面中” Admin “的右侧会多出”Shovel Status” 和” Shovel Management ” 两个 Tab 页:

1584805362789

  1. 配置测试所需的 queue

在测试机 ubuntu16.04 中创建一个名为origin_queue,生产一个消息,执行过程如下:

1584805384639

生产一个消息之后 origin_queue 中的消息数量变为 1:

在测试机 ubuntu19.04 创建一个名为 destination_queue:

1584805438154

  1. 配置 shovel

登录单机实例的管理控制台,Admin -> Shovel Management。

1584805475511

配置完成后如下图:

1584805492565

通过 Shovel Status 可以看 Shovel 的状态:

1584805510156

配置成功后 origin_queue 的消息数量为已经为 0,而 destination_queue 的消息数量变为 1,可以看到数据已经迁移过来了:

1584806215754

查看 destination_queue 中的消息:

1584805750155

3.3 总结

1.使用 shovel 插件时,只需要在 source 节点进行配置,destination 节点不需要配置;同理,只需要在 source 节点上使用 shovel 插件,destination 节点无需使用该插件;

1584806526051

2.hovel 正常工作时,对于 source 节点来说,增加了一条用于 consumer 的 TCP 连接;对于 destination 节点来说,增加了一条用于 producer 的 TCP 连接,和普通客户端的连接行为没什么不同。

分享到微博

Previous

如何基于docker-swarm实现海量email的解析
Starter
MicroServ
Tutorials
Report
Blog