• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

Broker的主从架构是怎么实现的?

开发技术 开发技术 3周前 (09-07) 18次浏览

 

前言

上一篇文章我们一起聊了聊RocketMQ的NameServer的一些内部工作流程,了解了NameServer的部署和与Broker之间的联系,那么今天我们就来一起聊聊Broker的一些内部原理。

 

Master Broker与Slave Broker之间的消息同步

看过之前文章的小伙伴们都清楚,Broker是RocketMQ的核心模块,负责接收并存储消息,为了保证整个MQ的高可用,一般情况都会将Broker部署成集群,集群中的每一部分都由Master和Slave组成,那么Master与Slave之间的数据是如何保证同步一致的呢?

是Master主动把数据推送给Slave?还是Slave主动发送请求去Master拉取最新数据?

答案是第二种,RocketMQ的内部原理就是Slave不停的向Master发送请求拉取数据,也就是说这是一种Pull模式拉取消息,而不是Push模式推送消息。

 

Master Broker与Slave Broker实现读写分离了吗

上边我们了解到,Master Broker主要接收来自系统的请求,之后Slave Broker会向Master Broker发出拉取请求,同步数据。那么,当系统访问Broker获取数据的时候是什么样的过程呢?如果实现了读写分离,是不是Master Broker只负责消息的写入操作,Slave Broker只负责消息的读取呢?

其实不是这样的,当读取数据的时候,是既可能在Master Broker读取数据,也可能在Slave Broker读取数据的。

作为消费者,向MQ获取数据的时候,首先与Master Broker建立连接,并发送请求获取一批消息。

而此时,Master Broker不是直接返回消息给消费者的,而是会根据Master Broker的负载情况以及Slave Broker的同步情况,向消费者建议下次应该从Master Broker获取消息还是应该从Slave Broker获取消息。

具体什么时候会建议去Master Broker获取消息呢?

举个例子,如果在一段时间内Master Broker突然新增了大量的消息,而这时Slave Broker同步这些消息也是需要一定的时间的,所以主从的数据是不一致的,为了保证读取消息的可靠性,就只能从Master Broker获取消息。

那么什么时候会建议去Slave Broker获取消息呢?

再看个例子,如果一段时间内,Master Broker由于业务原因接收了海量的并发请求,导致本身负载很重,这时对于消费者新发来的请求,如果继续从Master Broker获取消息,就会导致性能很慢,而且增加Master Broker服务器的压力,所以这个时候就会建议从Slave Broker获取消息了。

所以我们总结出来,当写入消息的时候,一般是选择Master Broker来写入的,而对于读取消息,从哪里获取数据,要视当时情况而定。所以不能说是完全的读写分离。

 

如果Slave Broker宕机怎么办

现在我们想想,如果Slave Broker宕机了,对于整体MQ系统来讲,会有多大的影响?

实际上,这种情况是没有太大的影响的,因为我们刚刚已经知道,所有的写请求都会发送给Master Broker,而所有的读请求通过Master Broker也可以进行下去。

所以Slave Broker宕机了,其实不影响整个MQ的运行过程,如果非要说出个影响了,那就是可供读取消息的机器少了一台而已,如果这时候出现海量并发读取消息的情况,性能会变差。

所以,Slave Broker宕机,一般会有监控系统监控的到,维护人员及时手动处理重新启动就可以了。

 

如果Master Broker宕机怎么办

现在我们假设,Master Broker突然宕机了,对于MQ整体上有什么影响呢.

这种情况对于消息的写入和读取就会产生影响了。但是我们知道,在Slave Broker上是有一份与Master Broker相同的备份数据的,只不过可能存在消息同步的过程中宕机的情况,导致部分数据丢失。

那么RocketMQ可以自动将Slave切换为Master吗?答案是否定的。

在RocketMQ4.5之前,一旦Master发生故障,Slave是没法自动切换成Master提供服务的。

在这种情况下,就需要运维人员手动修改Slave Broker的配置,重启服务将其切换为Master,这样不仅过程麻烦,而且中途还会发生服务不可用的状况,没有真正的实现高可用

 

Dledger实现RocketMQ的高可用

在RocketMQ4.5后,针对于上边说到的情况有了新的解决方案,就是Dledger。

小伙伴们一定会问,Dledger是什么呢?

Dledger是一个基于Raft协议实现的机制,暂时知道这里就可以了,至于什么是Raft,Dledger原理这里就先不聊了,那又是一个大的话题,感兴趣的小伙伴可以自行百度了解。

我们主要要聊的是基于Dledger可以实现RocketMQ的高可用主从自动切换效果。

简单的解释一下,就是当Master Broker宕机的时候,就可以在多个Slave Broker中根据Dledger机制进行leader选举,选出一个新的Master对外继续提供服务。整个过程可能在10秒或几十秒的时间,这样的话就实现了主从切换的自动化了。

 

总结

今天我们主要聊了聊Broker的主从架构,下边的文章我们将继续探索RocketMQ的生产部署架构,欢迎小伙伴们持续关注。

 

 

往期文章推荐:

中间件专辑:

什么是消息中间件?主要作用是什么?

常见的消息中间件有哪些?你们是怎么进行技术选型的?

你懂RocketMQ 的架构原理吗?

聊一聊RocketMQ的注册中心NameServer

算法专辑:

和同事谈谈Flood Fill 算法

Broker的主从架构是怎么实现的?

 


喜欢 (0)