• RabbitMQ高可用原理


    原文链接:https://www.jianshu.com/p/63642a48b9ec

    RabbitMQ的优缺点

    在正式的聊聊集群的原理之前,我们先简单了解下RabbitMQ的优缺点,然后为什么要使用RabbitMQ的集群模式,他能为我们解决那些问题,各种不同的集群模式有什么区别,又有什么优缺点;

    RabbitMQ的优缺点

    RabbitMQ的优点,我在Centos7下RabbitMQ的搭建其实已经介绍过了,无外乎三大点:解耦、削峰、异步通讯等,我们这里简单提下,但是相对于优点来说,RabbitMQ同样也有缺点:

    1. 增加了系统应用的复杂性
    2. RabbitMQ服务如果出现问题,则整个服务将会瘫痪
    3. 新增了很多异常情况的处理, 比如消息丢失、消息消费失败, 消息重复消费等
    4. RabbitMQ服务在高并发情况下很容易出现性能瓶颈,进而影响整个系统的运行

    其中1和3的问题都可以通过代码和配置来解决,但是问题2和4就不好解决了,为了解决上面的问题,就出现了RabbitMQ服务的集群

    RabbitMQ两种集群

    普通集群

    什么是普通集群呢? 就是在多个联通的服务器上安装不同的RabbitMQ的服务,这些服务器上的RabbitMQ服务组成一个个节点,通过RabbitMQ内部提供的命令或者配置来构建集群,形成了RabbitMQ的普通集群模式

     
    image
    • 当用户向服务注册一个队列,该队列会随机保存到某一个服务节点上,然后将对应的元数据同步到各个不同的服务节点上
    • RabbitMQ的普通集群模式中,每个RabbitMQ都保存有相同的元数据
    • 用户只需要链接到任一一个服务节点中,就可以监听消费到对应队列上的消息数据
    • 但是RabbitMQ的实际数据却不是保存在每个RabbitMQ的服务节点中,这就意味着用户可能联系的是RabbitMQ服务节点C,但是C上并没有对应的实际数据,也就是说RabbitMQ服务节点C,并不能提供消息供用户来消费,那么RabbitMQ的普通集群模式如何解决这个问题呢?
    • RabbitMQ服务节点C发现自己本服务节点并没有对应的实际数据后,因为每个服务节点上都会保存相同的元数据,所以服务节点C会根据元数据,向服务节点B(该服务节点上有实际数据可供消费)请求实际数据,然后提供给用户进行消费
    • 这样给用户的感觉就是,在RabbitMQ的普通集群模式中,用户连接任一服务节点都可以消费到消息
      -普通集群模式的优点:提高消费的吞吐量

    普通集群模式的原理比较简单,但是并不能真正意义上的实现高可用,他也存在以下的以下缺点:

    1. 为了请求RabbitMQ的实际数据以提供给用户,可能会在RabbitMQ内部服务节点之间进行频繁的进行数据交互,这样的交互比较耗费资源
    2. 当其中一个RabbitMQ的服务节点宕机了,那么该节点上的实际数据就会丢失,用户再次请求时,就会请求不到数据,系统的功能就会出现异常

    那么该怎么解决上述的问题呢?

    镜像集群模式

    为了解决上面普通模式的两个显著的缺点,RabbitMQ官方提供另外一种集群模式:镜像集群模式

     
    image

    镜像集群模式和普通集群模式大体是一样的,不一样的是:

    • 生产者向任一服务节点注册队列,该队列相关信息会同步到其他节点上
    • 任一消费者向任一节点请求消费,可以直接获取到消费的消息,因为每个节点上都有相同的实际数据
    • 任一节点宕机,不影响消息在其他节点上进行消费

    镜像集群模式是怎么开启的呢?这里简单说下,在普通集群模式的基础上,我们可以通过web控制端来配置数据的同步策略,可以配置同步所有的节点,也可以配置同步到指定数量的服务节点

    虽然镜像集群模式能够解决普通集群模式的缺点,当任一节点宕机了,不能正常提供服务了,也不影响该消息的正常消费,但是其本身也有相应的缺点:

    1. 性能开销非常大,因为要同步消息到对应的节点,这个会造成网络之间的数据量的频繁交互,对于网络带宽的消耗和压力都是比较重的
    2. 没有扩展可言,rabbitMQ是集群,不是分布式的,所以当某个Queue负载过重,我们并不能通过新增节点来缓解压力,因为所以节点上的数据都是相同的,这样就没办法进行扩展了

    对于镜像集群而言,当某个queue负载过重,可能会导致集群雪崩,那么如何来减少集群雪崩呢?我们可以通过HA的同步策略来实现

    HA的同步策略如下:

    HA-modeHA-params说明
    all 镜像队列将会在整个集群中复制。当一个新的节点加入后,也会在这个节点上复制一份。
    exactly count 镜像队列将会在集群上复制count份。如果集群数量少于count时候,队列会复制到所有节点上。
    如果大于Count集群,有一个节点crash后,新进入节点也不会做新的镜像。(可以阻止集群雪崩)
    nodes node name 镜像队列会在node name中复制。如果这个名称不是集群中的一个,这不会触发错误。
    如果在这个node list中没有一个节点在线,那么这个queue会被声明在client连接的节点。


    作者:AmosZhu
    链接:https://www.jianshu.com/p/63642a48b9ec
    来源:简书
    著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。
  • 相关阅读:
    【33】避免遮掩继承而来的名称
    调用异步方法
    Python 调用C++
    【37】绝不重新定义继承而来的缺省参数值
    【36】绝不重新定义继承而来的non-virtual方法
    【38】通过复合塑模出Has-A 或根据某物实现出
    【转】C++ function、bind以及lamda表达式
    mongodb
    mongodb
    mongodb
  • 原文地址:https://www.cnblogs.com/fswhq/p/13859597.html
Copyright © 2020-2023  润新知