浅谈消息队列的高可用性

  • Post author:
  • Post category:其他



注:该文是本博主记录学习之用,没有太多详细的讲解,敬请谅解!



一、RabbitMQ的高可用性

RabbitMQ是基于主从模式实现高可用,有三种模式:单机模式、普通集群模式,镜像集群模式。


  1. 单机模式


    普通单机模式 ,一般本地demo用,没有特别之处。


  2. 普通集群模式


    普通集群模式意思就是多台服务器启动多个RabbitMQ实例,一个服务器一个实例。创建的queue只会放到一个RabbitMQ实例上,其他实例同步queue的元数据,这样的方式就会导致出现两种情况:

    1)消费者每次随机连接一个实例然后拉取数据,有数据拉取的性能开销。

    2)要么固定连接那个queue所在实例消费数据,存在单实例的性能瓶颈。

如果那个放queue的实例宕机了,会导致接下来其他实例就无法从那个实例拉取,如果你开启了消息持久化,让RabbitMQ落地存储消息的话,消息不一定会丢,得等这个实例恢复了,然后才可以继续从这个queue拉取数据。

这方案主要是提高吞吐量的,就是说让集群中多个节点来服务某个queue的读写操作。

架构图如下所示:

在这里插入图片描述


  1. 镜像集群模式


    镜像集群模式就是创建的queue会存在于多个实例中,每次写消息到queue中都会同步到其他实例中,由此实现高可用。但是也导致有其他问题出现,

    1)性能开销太大,消息同步所有机器,导致网络带宽压力和消耗很重。

    2)扩展性低,如果某个queue负载很重,加机器,新增的机器也包含了这个queue的所有数据,并没有办法线性扩展queue。

架构图如下所示:

在这里插入图片描述



二、Kafka的高可用性

kafka是一个典型的分布式消息队列,它由多个broker组成,每个broker是一个节点;创建一个topic,这个topic可以划分为多个partition,每个partition可以存在于不同的broker上,每个partition就放一部分数据。

kafka 0.8以前,是没有HA机制的,就是任何一个broker宕机了,那个broker上的partition就废了,没法写也没法读,没有什么高可用性可言。

kafka 0.8以后,提供了HA机制,就是replica副本机制:

  • 每个partition的数据都会同步到其他机器上,形成自己的多个replica副本。
  • 然后所有replica会选举一个leader出来,那么生产和消费都跟这个leader打交道。
  • 其他replica就是follower。

架构图如下所示:

在这里插入图片描述



三、RocketMQ的高可用性

RocketMQ也是基于Master/Slave模式实现高可用,在集群模式的部署方式中,Master与Slave配对是通过指定相同的brokerName参数来配对,Master的BrokerId必须是0,Slave的BrokerId必须是大于0的数。一个Master下面可以挂载多个Slave,同一个Master下的多个Slave通过指定不同的BrokerId来区分。

RocketMQ有四种部署模式:


  1. 单个Master模式


    一旦Broker重启或者宕机时,会导致整个服务不可用。


  2. 多个Master模式

    优点:配置简单,单个Master宕机或重启维护对应用无影响,在磁盘配置为RAID10时,即使机器宕机不可恢复情况下,由于RAID10磁盘非常可靠,消息也不会丢(异步刷盘丢失少量消息,同步刷盘一条不丢),性能最高。

    缺点:单台机器宕机期间,这台机器上未被消费的消息在机器恢复之前不可订阅,消息实时性会收到影响。

    备注:当使用多master无slave的集群搭建方式时,master的brokerRole配置必须为ASYNC_MASTER。如果配置为SYNC_MASTER,则producer发送消息时,返回值的SendStatus会一直是SLAVE_NOT_AVAILABLE。


  3. 多Master多Slave模式—异步复制

    优点:即使磁盘损坏,消息丢失的非常少,但消息实时性不会受影响,因为Master宕机后,消费者仍然可以从Slave消费,此过程对应用透明,不需要人工干预,性能同多Master模式几乎一样。

    缺点:Master宕机,磁盘损坏情况,会丢失少量信息。

架构图如下所示:

在这里插入图片描述


  1. 多Master多Slave模式—同步双写

    优点:数据与服务都无单点,Master宕机情况下,消息无延迟,服务可用性与数据可用性都非常高。

    缺点:性能比异步复制模式稍低,大约低10%左右,发送单个消息的RT会稍高,目前主宕机后,备机不能自动切换为主机,后续会支持自动切换功能。

架构图如下所示:

在这里插入图片描述

在集群模式下,为了保证高可用,必须要保证备用Broker与主用Broker信息是一致的,在备用Broker初始化时设置的了定时任务,每个60秒调用SlaveSynchronize.syncAll()方法发起向主用Broker进行一次config类文件的同步,而消息数据的同步由主备Broker通过心跳检测的方式完成,每隔5秒进行一次心跳。 主用Broker提供读写服务,而备用Broker只提供读服务。

注:以上内容都是从网上各博客中学习而写,如果侵犯版权,敬请见谅!



版权声明:本文为weixin_43947588原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。