资讯专栏INFORMATION COLUMN

RabbitMQ双活方案

IT那活儿 / 689人阅读
RabbitMQ双活方案

点击上方“IT那活儿”,关注后了解更多内容,不管IT什么活儿,干就完了!!!





适用场景



RabbitMQ本身的优点众多,大家最看好的便是它的异步化提高系统抗峰值能力,然后便是系统及功能结构解耦,那么照此两点来说,它在整个系统中的作用是至关重要的。

那么如此重要,当然要考虑他的高可用性;混合云、多可用区、多机房的部署架构是大家普遍追寻的方案,但是怎么避免网络因素带来的影响呢?

RabbitMQ有很多种高可用方案,本文我们重点讲述federation插件方式,此方案一般适用于大型的分布式集群,可以避免因网络问题带来的消息差异、脑裂等情况。

Federation插件使RabbitMQ在不同Broker节点间进行消息传递而无须建立集群,在不同管理域(不同的用户和vhost、不同版本的RabbitMQ Erlang上)中的Broker或集群间传递消息,能容忍不稳定的网络连接情况。





前期准备



两台安装rabbitmq的机器 ,进行federation插件测试。





配置federation插件



1. 开启federation插件

rabbitmq-plugins enable rabbitmq_federation

rabbitmq-plugins enable rabbitmq_federation_management

2. 登入控制台配置策路

federation中的参数信息:

  • name: 新增的federation联合插件的上游名称,这个可以随便取名。

  • uri:上游federation联合rabbitmq的地址,上游是指订阅的服务器节点。

  • prefect count:一次性从上游rabbitmq服务器预期数据的最大数量,默认是1000。

  • reconnect delay:网络连接失败后下次重连的等待时间,默认是5秒。

  • Acknowledgement Mode:消息确认方式,on-confirm、on-publish和no-ack。含义分布如下:

① on-confirm,默认的确认方式,它需要下游消费者进行消息确认后才删除,是最可靠的消息处理方式。不管是网络错误还是消息节点失败都不会丢失消息。这种方式处理最慢。
② on-publish,上游节点将消息发送给下游节点后消息就进行确认了,这种情况在网络错误时可以进行重发,但是在消息节点失败时会丢失消息。
③ no-ack,不需要确认就可以进行消息删除。这种方式最不安全对于消息来说,但是却是最快的。
  • Trust User-ID:是否信任从上游服务器传来的用户id,默认是yes,设置成no,将会清空从上游服务器传来的user id信息。

接下来是专门提供给federation exchange交换器的参数:

  • Exchange:定义上游服务器的联合的exchange名称,默认情况下的取名与联合的exchange名称相同。

  • max hops:消息在被放弃或者说被消费前消息可以传递的最大的联合federation 连接长度,默认是1,一般情况连接长度等于联合的节点数量-1。

  • Expires:上游服务器节点保持节点信息的最长时间,单位毫秒,默认的是永久保存。

  • Message TTL:在上游节点中消息未被传递时可以保存的时长,单位毫秒,默认是永久保存。

  • HA Policy:检查一个联合exchange的上游queue中的x-ha-policy,用于确认该queue是否是一个HA的queue,默认是none表示不是一个HA的queue。

最后是federation queue的参数:

  • Queue:定义上游服务器的联合的queue名称,默认情况下的取名与联合的queue名称相同。

3. 定义联合查询federation

4. 定义同步策略policy

  • name标识名称。

  • pattern表示匹配的表达式,用法是正则表达式。

  • apply to表示应用在exchange还是queue上面,亦或两者都使用。

  • priority表示优先级,值越大,优先级越高。

  • definition用于定义使用的配置,这里我们定义的是federation联合,它有federation upstream set和 federation upstream两种方式,set表示集合,定义需要该策略的所有上游名称,一般我们都取值为all。

5. 状态查询

完成定义策略后,那么就会看到同步策略中开起的exchange、queue状态。

通过界面已经看到了federation联合查询对应的exchange和queue已经处于运行状态了,这个时候我们可以看到另一台控制台上的connection页签。

这个时候在rabbitmq服务器上面已经有了federation标志的连接,也就是我们刚才在前面定义的federation,在连接上面可以看到federation的名称及policy,说明已经同步到了另一台机器上面,同时我们也可以在exchange页签及queue页签中看到在另一台机器上面定义的federation联合exchange和queue名称。





功能验证



向交换机插入消息,验证是否可以进行同步:

登录另一个控制台:

从图中可以看到已经有一条消息过来,我们检查消息是否正确。

同步消息和手动插入的消息一致,至此federation插件验证完成。




本文作者:刘玉翀

本文来源:IT那活儿(上海新炬王翦团队)


文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/129564.html

相关文章

  • RabbitMQ集群架构模式

    摘要:一主备模式主备模式实现的高可用集群,一般在并发和数据量不高的情况下,这种模式很好用且简单。主备模式也称之为模式。多活集群架构如下 一、主备模式(Warren) 主备模式:实现RabbitMQ的高可用集群 ,一般在并发和数据量不高的情况下,这种模式很好用且简单。主备模式也称之为Waren模式。就是一个主/备方案(主节点如果挂了,从节点提供服务而已,主备切换。) 二、远程模式(Shove...

    Charles 评论0 收藏0
  • 消息中间件——RabbitMQ(二)各大主流消息中间件综合对比介绍!

    摘要:主流消息中间件介绍是由出品,是一个完全支持和规范的实现。主流消息中间件介绍是阿里开源的消息中间件,目前也已经孵化为顶级项目。 showImg(https://img-blog.csdnimg.cn/20190509221741422.gif);showImg(https://img-blog.csdnimg.cn/20190718204938932.png?x-oss-process=...

    hiyang 评论0 收藏0
  • 云时代数据中心架构与安全浅谈

    摘要:考虑到云数据中心未来承载业务系统的多样性和扩容空间,一般都会把架构设计成公有云和私有云相混合的融合架构。针对传统灾备系统建设面临的挑战,云数据中心更多倾向采用两地三中心的解决方案。近年数据中心处于高速的建设发展时期,十三五规划中也将大数据、云计算作为当前国家经济社会发展的重要战略内容,各政府部门对战略性新兴产业的大力扶持,以及对云计算、物联网、宽带和下一代网络的发展的高度重视,都给建设数据中...

    yy736044583 评论0 收藏0
  • 私有灾备云解决方案

    摘要:灾备服务支持本地灾备异地灾备公有云灾备两地三中心等多种服务方式,可根据业务特点和需求,灵活选择灾备方式,保证业务的和。公有云灾备架构公有云灾备服务支持多种业务部署方式,为云平台业务提供不同指标,控制云平台业务灾备成本。UCloudStack 云平台通过分布式存储系统保证本地数据的安全性,同时通过远程数据备份服务,为用户提供远程数据备份和容灾备服务,可以将本地云端数据统一归档、备份至远程云...

    youkede 评论0 收藏0
  • UCloud私有云双活数据中心解决方案,强效保障业务可靠性和连续性

    引言据信通院《2022云计算白皮书》报告,国内云计算市场达3000亿规模,云计算成为企业数字化转型的基础设施已是大势所趋。随着企业数字化转型的逐步深入,业务发展与IT基础架构演进密不可分,如何保障数据隐私安全和业务连续性,是 IT 建设中必须关注的问题。出于数据隐私和安全性考量,私有云解决方案成为构建数字化转型的基础底座,通过同城双活及两地三中心的高可用架构保障生产环境稳定性和业务过程连续性;同时...

    社区管理员 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<