RocketMQ是如何集群化部署来承载高并发的

RocketMQ单机可以支撑每秒 10w的QPS ,如果需要承载每秒几十万的请求,需要集群部署多台RocketMQ,将请求分散发给多台RocketMQ,让每台RocketMQ最高承载每秒 10w的QPS

如果RokcetMQ要存储海量数据,如何实现分布式的存储架构

MQ会接收大量的消息,这些消息并不是立马就会被所有的消费方获取过去消费的。所以一般MQ都得把消息在自己的本地磁盘存储起来,然后等待消费方获取消息去处理。

这种情况可能就会导致MQ会存储大量的消息,可能几亿条,甚至万亿条,这么多的消息在一台机器上肯定是没办法存储的,所以需要实现分布式存储架构来实现存储海量的消息。

  • 首先,发送消息到MQ的系统会把消息分散发送给不同的机器,假设一共有 1万条 消息,分散发送给 10台 机器,可能每台机器就是接收 1000条 消息。
  • 其次,每台机器上部署的RocketMQ进程一般称为 Broker ,每个 Broker 都会收到不同的消息,然后就会把这批消息存储在自己本地机器的磁盘上。这样,假设有1亿条消息,然后有10台机器部署了RocketMQ的Broker,理论上就是让每台机器存储1000万条的消息。

image.png
所以,本质上,RocketMQ存储海量消息的机制就是分布式存储。所谓的分布式存储,就是把数据分散在多台机器上来存储,每台机器存储一部分消息,这样多台机器加起来就可以存储海量消息了。

如何保证集群的RocketMQ架构的高可用性

上面的架构方式,如果出现了一台Broker突然宕机,就会导致RocketMQ里的一部分消息没有了,这就导致了MQ的不可靠和不可用。
RocketMQ针对这个问题采用的解决思路是 Broker主从架构以及多副本策略
简单来说,Broker是有 MasterSlave 两种角色。
image.png
Master Broker 负责接受生产者生产的消息。
Slave Broker 负责从 Master Broker 中拉取消息,同步 Master Broker 消息数据。
这样的话,同一条消息在RokcetMQ整个集群里就有两个副本了,一个在 Master Broker 里,一个在 Slave Broker 里。
这个时候,如果任何一个 Master Broker 出现了故障,还有一个 Slave Broker 上也有一份数据副本,可以保证数据的不丢失,还能继续对外提供服务,保证了MQ的可靠性和可用性

集群的RocketMQ,如何通过数据路由,知道访问哪个Broker

对于系统来说,需要讲消息发送到MQ里,然后还要从MQ里消费消息。
此时,需要已知系统里有哪些Broker,怎么知道连接到哪一台Broker上去发送和接收消息。
NameServer : 独立部署在几台机器上,然后所有的Broker都会把自己注册到NameServer上去,NameServer就会有相关的Broker数据信息。
然后,对于系统而言,如果要发送消息给Broker,就会找NameServer去获取路由信息,就能知道集群里有哪些Broker信息。如果要从Broker消费信息,也会找NameServer获取路由信息,去找到对应的Broker获取消息。
image.png

总结

Rocket可以采用多台机器集群的方式,去承载高并发的访问情况。
同时,多台机器集群的方式,可以使得海量数据可以分布式存储在不同的机器里的磁盘里面。
为了保证Broker的高可用性,会对Broker设置主从架构和多副本策略,保证一份消息在Master和Slave里都有相关的数据副本。
关于数据路由和Broker数据的获取,RocketMQ可以部署多个NameServer机器,让系统里的所有Broker注册到NameServer,在发送和消费消息的时候,都可以从NameServer通过路由获取相关的Broker信息。