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
Broker
Producer
Consumer
Topic
Message Queue
Producer相当于发信的人,Consumer相当于收信的人,Broker相当于每个地域的邮局,NameServer相当于由于的管理机构,Topic相当于信的类型。
小明要给小红写信问候,小明就是Producer(发送者),小红就是Consumer(消费者),小明首先带着信去当地的邮局管理机构(NameServer),告诉小明的信应该去哪个邮局才能传递给小红,小明这时就带着信去对应的邮局(Broker)进行信的投递。
小红知道小明给自己写了信,小红就会去当地的邮局管理机构(NameServer)询问来自小明地区的信应该去哪个邮局领取,管理机构高速小红去哪一个邮局领取,这时小红就去邮局(Broker)领取小明写的信。
RockerMQ集群模式主要分为四个部分:
1)单Master模式
单Master模式就是所谓单节点模式,一旦Broker宕机或者重启,会导致应用程序不可用,不建议使用。
2)多Master模式
集群中不存在Slave模式,全部都是Master节点,例如两个Master或者三个Master组成的集群模式。
3)多Master多Slave模式(异步)
集群中存在Master和Slave节点,每个Master节点配置一个Slave或者多个Slave节点,Slave只读不能写,Master和Slave组成一组,在集群中可以有多组Master-Slave,高可用采用异步复制的方式,主备之间数据同步存在短暂的消息延迟。
异步模式指的是:当发送者发送的消息成功到达在Broker后,Broker会立即向发送者反馈消息已经收到,然后将消息数据落盘,最后同步一份到Slave中。
4)多Master多Slave模式(同步)
集群中存在Master和Slave节点,每个Master节点配置一个Slave或者多个Slave节点,Slave只读不能写,Master和Slave组成一组,在集群中可以有多组Master-Slave,高可用采用同步双写的模式,和异步模式存在区别。
同步双写模式指的是:当发送者发生的消息到达Broker后,Broker需要将数据先落盘,然后同步数据到Slave节点,最后向发送者反馈消息已经收到。
5)总结
同步模式下的多Master多Slave模式比异步模式效率略低,并且性能也比异步模式消耗要高,因为同步模式Broker收到一条消息,首先会落盘然后同步给Slave,最后再反馈给发送者,而异步模式下,Broker在收到消息的一瞬间就会反馈给发送者消息已收到。
同步模式下可以保证消息的可靠性,会保证每一条消息丢失成功进行存储的,而异步模式下,虽然Broker收到消息可以立即反馈,但是数据落盘时如果MQ宕机,发送者已经收到确认的消息的,但是消息其实并没有存储到Broker中,就会导致消息数据存在丢失的现象。
至于选择哪种方案都可以,按需选择,4、5这两种方案也是常用的方案,如果不能接受消息数据丢失那么就采用同步双写模式,如果对数据的延迟性没有太高的要求可以采用异步模式。