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这两种方案也是常用的方案，如果不能接受消息数据丢失那么就采用同步双写模式，如果对数据的延迟性没有太高的要求可以采用异步模式。