rabbitmq系统学习(三)集群架构

RabbitMQ集群架构模式

主备模式

  1. 实现RabbitMQ的高可用集群,一般在并发和数据量不高的情况下,这种模型非常的好用且简单。主备模式也称为Warren模式
  2. HaProxy配置
listen rabbitmq_cluster
bind 0.0.0.0:5672 # 配置TCP模式
mode tcp #简单的轮询
balance roundrobin #主节点
server bhz76 192.168.11.76:5672 check inter 5000 rise 2 fall 3
server bhz77 192.168.11.77:5672 backup check inter 5000 rise 2 fall 3 # 备用节点
# 备注: rabbitmq集群节点配置 #inter 每隔五秒对mq集群做健康检查,2次正确证明服务器可用,3次失败证明服务器不可用,并且配置主备机制

远程模式

  1. 远程模式可以实现双活的一种模式,简称Shovel模式,所谓Shovel就是我们可以把消息进行不同数据中心的复制工作,我们可以跨地域的让两个mq集群互联

镜像模式(用的最多)

  1. 集群模式非常经典的就是Mirror镜像模式,保证100%数据不丢失,在实际工作中用的最多。并且实现集群非常的简单

异地多活模式

  1. 实现异地数据复制的主流模式,需要依赖rabbitmq的federation插件
  2. 采用双中心模式,需要在两套或多套数据中心各部署一套RabbitMQ集群,各中心RabbitMQ服务除了需要为业务提供正常的消息服务外,中心之间还需要实现部分队列消息共享

安装

  1. /etc/hostname 取名
  2. 复制/var/lib/rabbitmq/.erlang.cookie 文件到每台服务器
  3. rabbitmq-server -detached
  4. rabbitmqctl stop_app
  5. rabbitmqctl join_cluster --ram rabbit@bhz76 #主机名,ram内存方式存储,模式磁盘方式
  6. rabbitmqctl start_app
  7. 移除节点 rabbitmqctl forget_cluster_node rabbit@bhz24
  8. 修改集群名称 rabbitmqctl set_cluster_name rabbitmq_cluster1
  9. 查看集群状态 rabbitmqctl cluster_status

Haproxy

  1. 高可用负载均衡以及基于TCP(第四层)和HTTP(第七层)应用的代理软件,支持虚拟主机。
  2. 单进程,时间驱动模型显著降低了上下文切换的开销以及内存占用
  3. 在任何可用的情况下,单缓冲机制能以不复制任何数据的方式完成读写操作,这会节约大量的CPU时钟周期及内存宽带

KeepAlived

  1. 通过VRRP协议实现高可用功能,VRRP是Virtual Router RedundancyProtocol(虚拟路由器冗余协议)的缩写,它的出现目的是为了解决静态路由单点故障问题,它能够保证党个别节点宕机时,整个网络可以不间断地运行,所以,Keepalived一方面具有配置管理LVS负载均衡的功能,同时还具有对LVS下面节点进行健康检查的功能,另一方面也可以实现系统网络服务的高可用功能

延迟插件

  1. 消息的延迟推送、定时任务(消息)的执行。包括一些消息重试策略的配置使用,以及用于业务削峰限流、降级的异步延迟消息机制,都是延迟队列的实际应用场景
  2. rabbitmq插件库地址 www.rabbitmq.com/community-plugins.html
  3. 下载插件rabbitmq_delayed_message_exchange

互联网大厂SET架构

BAT/TMD大厂单元化架构设计衍变

  1. 单个大型分布式体系的集群,通过加机器+集群内部拆分(kv/mq、Mysql等),虽然具备一定的可扩展性,但是随着业务量的进一步增长,整个集群规模逐渐变得巨大,从而会在某个点上达到瓶颈,无法满足扩展性需求,并且大集群内核心服务出现问题,会影响全网所有用户
  2. 如滴滴打车、美团外卖,订单量巨大,每天上2000w,会面临以下问题
    1. 容灾问题
    2. 资源扩展问题
    3. 大集群拆分问题
  3. 同城“双活”架构
  4. 两地三中心架构
  5. SET化方案目标
    • 业务:解决业务遇到的扩展性和容灾等需求,支撑业务的高速发展
    • 通用性:架构侧形成统一通用的解决方案,方便各业务接入使用

SET化架构策略

  1. SET化架构设计
  1. 流量路由
    • 按照特殊的key(通常为userid)进行路由,判断某次请求该路由到中心集群还是单元化集群;
  2. 中心集群:
    • 未进行单元化改造的服务(通常不在核心交易链路,比如供应链系统)称为中心集群,跟当前架构保持一致
  3. 单元化集群:
    • 每个单元化集群只负责本单元内的流量处理,以实现流量拆分以及故障隔离
    • 每个单元化集群,前期只储存本单元产生的交易数据,后续会做双向数据同步,实现容灾切换需求
  4. 中间件(RPC、KV、MQ等):
    • RPC:对于SET服务,调用封闭在SET内;对于非SET服务,沿用现有路由逻辑
    • KV:支持分SET的数据生产和查询
    • MQ:支持分SET的消息生产和消费
  5. 数据同步:
    • 全局数据(数据量小且变化不大,比如商家的菜品数据)部署在中心集群,其他单元化集群同步全局数据到本单元化内
    • 未来演变为异地多活架构时,各单元化集群数据需要进行双向同步来实现容灾需要
  6. 集装箱式扩展
    • SET的封装性支持更灵活的部署扩展性,比如SET一键创建/下线,SET一键发布等
  7. SET化架构图

未完待续...

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券