RocketMQ集群的特点以及各种集群模式的介绍

文章目录

    • 1.RocketMQ集群中各角色的作用
    • 2.RocketMQ集群模式的种类
      • 2.1.集群模式的特点
      • 2.2.RockerMQ集群种类

1.RocketMQ集群中各角色的作用

RockerMQ集群架构:

Producer(生产者)需要将消息数据存储到MQ消息队列中,Producer会向NameServer询问我应该将消息数据存储在哪一个Broker中,NameServer会给Producer分配一个Broker,然后由Producer将消息数据存储在指定的Broker中。

每一个Broker都会将自己的信息主动上报到NameServer,由NameServer进行统一管理,当NameServer已经有了所有Broker的信息后,就可以给Producer分配可以存储消息数据的Broker。

Consumer(消费者)需要消费消息数据,消息数据都存储在Broker中,Consumer会向NameServer询问我应该从哪一个Broker中读取消息数据,这时NameServer就会将消息所在的Broker信息返回给Consumer,Consumer再去指定的Broker中消费数据。

Broker有主从复制的概念,主节点产生的消息数据会同步到从节点,保证数据的高可用。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pOkuqa95-1687749735370)(https://gitcode.net/weixin_44953658/typorajiangxl-image/-/raw/master/MQ/RocketMQ角色.jpg)]

RockerMQ各角色的作用

  • NameServer

    • RockerMQ中最核心的角色,负责管理所有的Broker,生产者和消费者都是通过NameServer分配的Broker来存储或读取消息数据的。
    • 程序连接MQ时也是连接的NameServer的地址。
  • Broker

    • 所有的消息数据都存储在Broker中,生产者发送消息通过NameServer找到指定的Broker进行存储,消费者消费数据时也会通过NameServer找到对应的Broker进行消息的读取。
    • 所有的Broker会主动将自己的状态信息上报到NameServer。
    • Broker存在主从复制的概念。
  • Producer

    • 消息的发送者:Producer—>NameServer—>Broker
  • Consumer

    • 消息的消费者:Comsumer—>NameServer—>Broker
  • Topic

    • 区分消息的种类,一个发送者可以发送消息给一个或者俄夺各Topic,一个消息的接收者也可以订阅一个或者多个Topic消息。
  • Message Queue

    • 相当于是Topic分类的更细化的种类,也就是Topic的分区,用于并行发送和接收消息。

Producer相当于发信的人,Consumer相当于收信的人,Broker相当于每个地域的邮局,NameServer相当于由于的管理机构,Topic相当于信的类型。

小明要给小红写信问候,小明就是Producer(发送者),小红就是Consumer(消费者),小明首先带着信去当地的邮局管理机构(NameServer),告诉小明的信应该去哪个邮局才能传递给小红,小明这时就带着信去对应的邮局(Broker)进行信的投递。

小红知道小明给自己写了信,小红就会去当地的邮局管理机构(NameServer)询问来自小明地区的信应该去哪个邮局领取,管理机构高速小红去哪一个邮局领取,这时小红就去邮局(Broker)领取小明写的信。

2.RocketMQ集群模式的种类

2.1.集群模式的特点

RockerMQ集群模式主要分为四个部分:

  • NameServer
    • NameServer是一个几乎无状态的节点,可以直接部署多个节点,节点之间不需要任何的数据同步,因为每一个Broker运行起来之后,都会向每一个NameServer发送当前Broker的信息。
  • Broker
    • Broker的部署会相对比较复杂,Broker分为Master和Slave节点,一个Master可以对应多个Slave,但是一个Slave只能对应一个Master。
    • 一组Master和Slave的Broker是通过指定相同的BrokerName来组成的,Master和Slave的BrokerID不同,BrokerID为0表示是Master节点,非0表示是Slave节点,Master节点可以部署多个,Master和Slave之间会同步数据。
    • 每个Broker和NameServer集群中的所有节点都建立TCP长连接,定时将注册Topic信息同步到所有是NameServer。
  • Producer
    • Producer与NameServer中的某一个节点(随机选择)建立TCP长连接,定期从NameServer中读取Topic路由信息,并且向提供Topic服务的Broker Master节点建立长连接,定时向Master发送心跳检测。
  • Consumer
    • Consumer与NameServer中的某一个节点(随机选择)建立TCP长连接,定期从NameServer中读取Topic路由信息,并且向提供Topic服务的Broker Master/Slave建立长连接,定时向Master和Slave发送心跳检测,Consumer既可以从Master读取消息也可以从Slave中读取消息,具体规则由Broker配置决定。

2.2.RockerMQ集群种类

1)单Master模式

单Master模式就是所谓单节点模式,一旦Broker宕机或者重启,会导致应用程序不可用,不建议使用。

2)多Master模式

集群中不存在Slave模式,全部都是Master节点,例如两个Master或者三个Master组成的集群模式。

  • 优点:配置简单,单个Master宕机或者重启后对应用无任何影响,当磁盘配置的是RAID10时,即使机器宕机不可恢复的情况下,消息数据也不会丢失,异步刷盘丢失少量消息,同步刷盘不丢失数据性能最高。
  • 缺点:单台节点宕机期间,这台节点上的消息没有被消费时,在节点恢复之前不可以被消费,消息的实时性会受到影响。

3)多Master多Slave模式(异步)

集群中存在Master和Slave节点,每个Master节点配置一个Slave或者多个Slave节点,Slave只读不能写,Master和Slave组成一组,在集群中可以有多组Master-Slave,高可用采用异步复制的方式,主备之间数据同步存在短暂的消息延迟。

异步模式指的是:当发送者发送的消息成功到达在Broker后,Broker会立即向发送者反馈消息已经收到,然后将消息数据落盘,最后同步一份到Slave中。

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

4)多Master多Slave模式(同步)

集群中存在Master和Slave节点,每个Master节点配置一个Slave或者多个Slave节点,Slave只读不能写,Master和Slave组成一组,在集群中可以有多组Master-Slave,高可用采用同步双写的模式,和异步模式存在区别。

同步双写模式指的是:当发送者发生的消息到达Broker后,Broker需要将数据先落盘,然后同步数据到Slave节点,最后向发送者反馈消息已经收到。

  • 优点:数据与服务都无单点故障,Master宕机情况下,消息无延迟,服务可用性与数据可用性都非常高;
  • 缺点:性能比异步复制模式略低(大约低10%左右),发送单个消息的RT会略高,且目前版本在主节点宕机后,备机不能自动切换为主机。

5)总结

同步模式下的多Master多Slave模式比异步模式效率略低,并且性能也比异步模式消耗要高,因为同步模式Broker收到一条消息,首先会落盘然后同步给Slave,最后再反馈给发送者,而异步模式下,Broker在收到消息的一瞬间就会反馈给发送者消息已收到。

同步模式下可以保证消息的可靠性,会保证每一条消息丢失成功进行存储的,而异步模式下,虽然Broker收到消息可以立即反馈,但是数据落盘时如果MQ宕机,发送者已经收到确认的消息的,但是消息其实并没有存储到Broker中,就会导致消息数据存在丢失的现象。

至于选择哪种方案都可以,按需选择,4、5这两种方案也是常用的方案,如果不能接受消息数据丢失那么就采用同步双写模式,如果对数据的延迟性没有太高的要求可以采用异步模式。

你可能感兴趣的:(ActiveMQ,java-rocketmq,rocketmq,java)