消息队列架构设计思路(消息队列框架有哪些)

本文将详细阐述消息队列代理主从架构的设计方案。这篇文章的内容质量很高，所以边肖会分享给大家参考。希望你看完这篇文章后有所了解。

今天，我们来了解一下消息队列设计的底层模块，即Broker的架构设计。

Master Broker 与Slave Broker 消息如何同步

正如我们之前所知，如果您希望Broker支持高可用性，您应该将其设计为主从架构。前面的分布式存储也讲了很多这个架构，大家可以自己查历史文章。

首先我们来看第一个问题。为了确保我们的MQ中的数据不会丢失并支持可用性，我们将代理设计为主从模式，即一个主代理对应多个从代理。

这样做的好处是，当我们的主代理收到消息时，它会将消息同步到从代理，因此即使主代理关闭，从代理上仍然会有数据。

如上所述，让我们考虑一下这个主代理如何与从代理同步数据。一般有两种方案：

主代理主动向从代理推送消息。

从属代理向主代理发送一个请求，以提取消息数据。

我们采用了更可靠的二次拉取方案，让从代理不断向主代理发送请求，以拉取方式拉取消息。

MQ 实现读写分离吗？

从上面我们已经知道，Master Broker主要用于接收消息，然后与Slave Broker同步，所以Slave Broker也有一个相同的数据。

在这种情况下，我们的下一个问题是，消费者系统是从主代理还是从代理获取消息？

事实上，我们不能简单地从主人或奴隶那里得到它。我们应该更聪明。有可能从主人或奴隶那里得到它。

作为一个消费者系统，在获取消息时，首先会向Master Broker发送一个请求，然后Master Broker会向消费者系统返回一批消息。

然后，当主代理将消息返回给消费系统时，它将根据自己的负载和与从代理的同步，建议消费系统下次是从主代理还是从从代理获取消息。

例如，现在Master负载很重，它必须抵抗100，000个写并发。那你就得从它那里得到消息，这会给师父带来更重的负担。然后主代理会建议你去从代理获取消息。

比如现在Master Broker已经收到了100万条消息。结果，Slave Broker机器无缘无故就同步到了96万条消息，落后了4万条消息。此时作为一个消费系统，可能已经获取了96万条消息，所以下次只能从Master拉消息。因为Slave Broker太慢，无法同步消息，所以我们无法从那里获取最新消息。

因此，这一切都将由Master Broker根据实际负载情况决定从哪里获取消息。

如图所示：

写消息时，通常必须选择Master Broker来写。

当消费消息时，可以在主代理中拉它们或者转到从代理。

拉取的，视当时情况决定。

Slave Broker 挂了有何影响?

现在我们看下一个问题， 假如Slave Broker 挂掉了，会对我们整个系统有什么影响?影响是有一点的，但是不太大，无足畏惧。

因为消息在写入的时候是全部发到 Master Broker 上的，然后拉取消息的时候也可以走 Master Broker，只是有一些消息拉取可能是走  Slave Broker 上的。

所以，假如 Slave Broker 挂掉了，我们消息写入和获取都是可以走 Master Broker  的，是不会对我们整体系统造成大影响的。就是会可能导致Master Broker 读写压力增加。

Master Broker 挂掉了该怎么办?

上面我们分析了 Slave Broker 挂了并不影响整体系统，现在假设我们的 Master Brokker 抽风了挂掉了，会怎么样呢?

这个时候，对于消息的写入和获取就有一定影响了，但是就本质而言，Slave Broker 上是有一份数据的，只不过是有一些数据还没来得及从 Master  Broker 中同步，一般我们就要设计 Slave Broker 自动接管 Master Broker 机制了，可以有两种方案解决：

• 人工运维，通过人手工切换

• 利用工具自动切换

手动切换

在 RocketMQ4.5 版本之前，都是这样的人工运维方式，当Master Broker 挂掉之后，人为的去修改配置，将 Slave Broker  进行相关修改，然后重启机器就给调整为 Master Broker，期间就是有点麻烦，而且会造成短时间的不可用。

采用如上方式，并不能彻底的实现高可用，因为没办法自动将Slave Broker 升为 Master Broker。

基于Dledger 实现 MQ 自动切换

RocketMQ4.5 之后，开始引入新的机制，那就是Dledger，Dledger 是基于Raft  协议实现的机制，后面会单独对其底层原理进行详细讲解。我们先来看看基于Dledger 怎么实现 自动切换。

RocketMQ 引入 Dledger 之后，就可以让一个 Master Broker 对应多个 Slave Broker  也就是说一份数据会有多份副本。比如我们一个Master Broker 对应 两个 Slave Broker。

此时，如果一个Master Broker 宕机的话，还是会有多个 Slave ，然后通过Dledger 技术以及Raft 协议进行leader  选主，选主算法其实我前面有一篇专门讲了的，可以看看(面试是不是经常被问到分布式系统核心问题，这一次没人难倒你)。这样就会选出新的Master broker  对外提供服务。

如此一来，整个过程会很快，大概十几秒或者几十秒就能完成切换动作，完全的全自动的将Slave Broker 选为Master broker  对外提供服务，实现高可用模式。

关于消息队列Broker主从架构的设计方案是什么就分享到这里了，希望