Broker的主从架构

为了包管MQ的数据不丢失而且具备肯定的高可用性，以是一般都是得将Broker部署成Master-Slave模式的，也就是—个Master Broker对应一个Slave Broker Master必要在吸收到消息之后，将数据同步给Slave，如许一旦Master Broker挂了，还有Slave上有一份数据。
Master上有全量数据，但是去Master上消费，Master压力会很大，但去Slave上去读，数据不全，但是很快。
那RocketMQ怎样弃取？ ---》固然是两者相结合。
比如说，Master上有10w条数据，第一次先去Master上读，

• 如果Master发现她只想读第5W条数据，那就直接让他去Slave上读，下次这个消费者也去Slave上读了，
  

• 如果Master发现她要读第10W条数据，要读的比较新，那就让他去Master上读，下一次也是Master上读。
  
• 如果Master负载很重，再从Master上拉取数据就不合适了。
  

1 Broker的主从架构有没有实现读写分离？

作为消费者的系统在获取消息的时间，是从Master Broker获取的?还是从Slave Broker获取的?实在都不是。答案是:有大概从Master Broker获取消息，也有大概从Slave Broker获取消息。
作为消费者的系统在获取消息的时间会先发送请求到Master Broker上去，请求获取一批消息，此时Master Broker是会返回一批消息给消费者系统的
Master Broker在返回消息给消费者系统的时间，会根据当时Master Broker的负载环境和Slave Broker的同步环境，向消费者系统发起下一次拉取消息的时间是从Master Broker拉取还是从Slave Broker拉取。
举个例子，要是这个时间Master Broker负载很重，本身要抗10万写并发了，你还要从他这里拉取消息，给他加重负担，那肯定是不合适的。以是此时Master Broker就会发起你从Slave Broker去拉取消息。或者举别的一个例子，本身这个时间Master Broker上都已经写入了100万条数据了，结果Slave Broke不知道啥缘故原由，同步的特别慢，才同步了96万条数据，落伍了整整4万条消息的同步，这个时间你作为消费者系统大概都获取到96万条数据了，那么下次还是只能从Master Broker去拉取消息。因为Slave Broker同步太慢了，导致你没法从他那里获取更新的消息了。
以是这一切都会由Master Broker根据环境来决定。
2 RocketMQ版本不同broker主从主动切换的区别

在RocketMQ 4.5版本之前，都是用Slave Broker同步数据，尽量包管数据不丢失，但是一旦Master故障了，Slave是没法主动切换成Master的。
以是在这种环境下，如果Master Broker宕机了，这时就得手动做一些运维操作，把Slave Broker重新修改一些配置，重启机器给调整为Master Broker，这是有点麻烦的，而且会导致中央一段时间不可用。
在RocketMQ 4.5之后，这种环境得到了改变，因为RocketMQ支持了一种新的机制，叫做Dledger。
简朴来说，把Dledger融入RocketMQ之后，就可以让一个Master Broker对应多个Slave Broker，也就是说一份数据可以有多份副本，比如一个Master Broker对应两个Slave Broker。
此时一旦Master Broker宕机了，就可以在多个副本，也就是多个Slave中，通过Dledger技能和Raft协议算法进行leader推举，直接将一个Slave Broker推举为新的Master Broker，然后这个新的Master Broker就可以对外提供服务了。
整个过程大概只要几秒的时间就可以完成，如许的话，就可以实现Master Broker挂掉之后，主动从多个Slave Broker中推举出来一个新的Master Broker，继续对外服务，一切都是主动的。
3 Topic作为一个数据集合是怎么在Broker集群里存储的

起首我们来想一下，比如我们有一个订单Topic，大概订单系统天天都会往里面投递几百万条数据，然后这些数据在MQ集群上还得保存好多天，那么最终大概会有几千万的数据量，这还只是一个Topic。
那么如果有很多的Topic，并且里面都有大量的数据，最终加起来的总和大概是一个惊人的数字，此时这么大量的数据本身是不太大概存放在一台机器上的。如果一台机器没法放下那么多的数据，应该怎么办呢?
很简朴，分布式存储。
我们可以在创建Topic的时间指定让他里面的数据分散存储在多台Broker机器上，比如一个Topic里有1000万条数据，此时有2台Broker，那么就可以让每台Broker上都放500万条数据。
如许就可以把一个Topic代表的数据集合分布式存储在多台机器上了。

4 生产者系统是怎样将消息发送给Broker的？

在发送消息之前，得先有一个Topic，然后在发送消息的时间你得指定你要发送到哪个Topic里面去。
接着既然你知道你要发送的Topic，那么就可以跟NameServer建立一个TCP长毗连，然后定时从他那里拉取到最新的路由信息，包括集群里有哪些Broker，集群里有哪些Topic，每个Topic都存储在哪些Broker上。
然后生产者系统天然就可以通过路由信息找到自己要投递消息的Topic分布在哪几台Broker上，此时可以根据负载平衡算法，从里面选择一台Broke机器出来，比如round robine轮询算法，或者是hash算法，都可以。
总之，选择一台Broker之后，就可以跟那个Broker也建立一个TCP长毗连，然后通过长毗连向Broker发送消息即可。
生产者肯定是投递消息到Master Broker的，然后Master Broker会同步数据给他的Slave Brokers，实现一份数据多份副本，包管Master故障的时间数据不丢失，而且可以主动把Slave切换为Master提供服务。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。