RocketMQ的架构原理和使用

集群化部署

 
假设RocketMQ部署在一台机器上,即使这台机器配置很高,但是一般来说一台机器也就是支撑10万+的并发访问。
那么这个时候,假设有大量的系统都要往RocketMQ里高并发的写入消息,可能达到每秒有几十万请求,这个时候怎么办呢?
没关系,RocketMQ是可以集群化部署的,可以部署在多台机器上,假设每台机器都能抗10万并发,然后你只要让几十万请求分散到多台机器上就可以了,让每台机器承受的QPS不超过10万不就行了。
notion image
这其实就是RocketMQ集群化部署抗下高并发的主要原理

存储海量消息

MQ会收到大量的消息,这些消息并不是立马就会被所有的消费方获取过去消费的,所以一般MQ都得把消息在自己本地磁盘存储起来,然后等待消费方获取消息去处理。
既然如此,MQ就得存储大量的消息,可能是几百万条,可能几亿条,甚至万亿条,这么多的消息在一台机器上肯定是没法存储的,RocketMQ是如何分布式存储海量消息的呢?
其实发送消息到MQ的系统会把消息分散发送给多台不同的机器,假设一共有1万条消息,分散发送给10台机器,可能每台机器就是接收到1000条消息,如下图:
notion image
其次,每台机器上部署的RocketMQ进程一般称之为Broker,每个Broker都会收到不同的消息,然后就会把这批消息存储在自己本地的磁盘文件里
这样的话,假设你有1亿条消息,然后有10台机器部署了RocketMQ的Broker,理论上不就可以让每台机器存储1000万条消息了吗?
所以本质上RocketMQ存储海量消息的机制就是分布式的存储
所谓分布式存储,就是把数据分散在多台机器上来存储,每台机器存储一部分消息,这样多台机器加起来就可以存储海量消息了!

高可用保障

要是任何一台Broker突然宕机了怎么办?那不就会导致RocketMQ里一部分的消息就没了吗?这就会导致MQ的不可靠和不可用,这个问题怎么解决?
RocketMQ的解决思路是Broker主从架构以及多副本策略。

NameServer

NameServer

Broker数据持久化

Broker数据持久化

多副本同步+Leader自动切换

RocketMQ的Broker的主从架构原理

RocketMQ集群权限机制

RocketMQ集群权限机制

RocketMQ集群消息轨迹的追踪

RocketMQ集群进行消息轨迹的追踪

MQ集群迁移过程中的双写+双读技术方案

MQ集群迁移过程中的双写+双读技术方案。

生产者原理

RocketMQ生产者原理

消费者原理

RocketMQ的消费者原理

Broker的网络通信的架构

Broker的网络通信的架构是如何基于Netty进行扩展的

消息丢失解决方案

RocketMQ消息丢失解决方案

重复消息解决方案

RocketMQ重复消息解决方案

消息处理失败解决方案

RocketMQ消息处理失败解决方案

消息乱序的问题解决方案

RocketMQ消息乱序的问题解决方案

消息积压问题解决方案

消息积压问题解决方案

数据过滤机制

RocketMQ数据过滤机制

延迟消息机制

RocketMQ延迟消息机制