网站 目录 结构,wordpress传到ftp,谷城网站开发,wordpress字菜单为了保证MQ的数据不丢失而且具备一定的高可用性#xff0c;所以一般都是得将Broker部署成Master-Slave模式的#xff0c;也就是—个Master Broker对应一个Slave Broker Master需要在接收到消息之后#xff0c;将数据同步给Slave#xff0c;这样一旦Master 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提供服务。
