消息队列Broker主从架构详细设计方案

MQ 实现读写分离吗?

通过上面我们已经知道，Master Broker 主要用来接收消息的，然后会同步到 Slave Broker 中，因此 Slave Broker 也有一份一模一样的数据。

既然如此，那我们接下来一个问题是，消费者系统是从 Master Broker 中获取消息还是从Slave Broker 中获取呢?

其实我们不能那么简单从 master 还是 slave 中获取，应该更智能一点，既有可能去 Master 中获取也有可能从 Slave 中去获取。

作为消费者系统，在获取消息的时候会首先发送请求到 Master Broker 上去，然后Master Broker 会返回一批消息给消费者系统。
 

接着 Master Broker 在返回消息给消费者系统的时候，会根据自身负载情况以及和Slave 同步情况，向消费者系统建议下一次是从 Master Broker 获取还是 Slave Broker 中获取消息。

比如，现在Master 负载很重，本身要抗 10 万的写并发，然后你还要从它这里来获取消息，就会给 Master 带来更重的负担，那么Master Broker 就会建议你去Slave Broker 中去拉取消息。

还比如，现在Master Broker 收到了100 万条消息，结果Slave Broker 机器不知道怎么原因，才同步到 96 万条消息，落后了 4 万条消息数据，此时，作为消费者系统可能都获取到了 96 万条数据了，那么下次还是只能从Master 中拉取消息。因为，Slave Broker 同步消息太慢了，导致我们没法从那里获取最新的消息了。

所以，这一切都会由Master Broker 依据实际负载情况来决定从哪获取消息。

（编辑：甘孜站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!