RocketMQ的基本的架构原理

Posted 2023-05-02

参考技术A 这么想RocketMQ单机可以扛下10万的并发，那么让多台机器一起来提供服务，让几十万甚至更多的请求分散到这部署的多台机器是不是就可以了，让每台机器承受的QPS不超过10万就好了。

存储数据也是同样的道理，把这海量的数据分散发送到这多台机器上每台机器保存一部分数据，分布式存储这些信息。RocketMQ的实现原理就是，它会跑一个Broker进程，每个Broker都会收到不同的消息，然后就会把这批消息存储在自己的本地磁盘文件里。

RockerMQ采用的解决思路是：Broker主从架构以及多副本策略。

Master Broker 收到消息之后，会同步给slave Broker，这样Slave Broker就有一份和Master Broker一模一样的副本消息数据。这种情况下，如果一个Master Broker 出现故障，还有一个Slave Broker上有副本数据，可以保证数据的不丢失还能继续提供服务，保证高可用。

生产者和消费者是如何知道有哪些Broker呢，是如何知道该连到那一台的Broker上去发送消息和消费消息呢，为了解决这问题，RockerMQ引入了NameServer的概念，它也是独立部署在几台机器上的，然后所有的Broker都会把自己注册到NameServer ,然后生产者，消费者从NameServer获取消息。

RocketMQ架构原理及名词概念

这节主要讲述RocketMQ的整体架构，和常用术语解释。当我们接触一个新东西的时候，一定要知道他的原理，只有知道原理之后，才会产生问题。只有带着问题去读源码才会事半功倍。

首先盗用官方的一张图片：（官方地址：http://rocketmq.apache.org/）

NameServer：从上图可以清楚的看到NameServer主要干了两件事情，服务发现和路由。如果你知道zookeeper就可以很好理解NameServer了。NameServer就是一个轻量级的zookeeper。多个NameServer可以横向扩展，且它们之间没有任何通信。

Broker：Broker是RocketMQ的核心组成部分，通过轻量级的Topic和队列机制来维护消息存储，Broker支持消息Push和Pull模式。支持千亿级别的消息堆积能力，总之很强大。

Producer：顾名思义生产者，Producer去NameServer获取Broker列表，进行轮询发送消息。每个生产者都有一个ID(编号)，多个生产者实例可以共用同一个ID。同一个ID下所有实例组成一个生产者集群。

Consumer：顾名思义消费者，Consumer去NameServer获取Broker列表，进行消息消费，支持Push和Pull两种模式。每个订阅者也有一个ID(编号)，多个消费者实例可以共用同一个ID。同一个ID下所有实例组成一个消费者集群。

 

源码模块说明(RokcetMQ版本4.3.1)：

rocketmq-broker：服务端，接受消息，存储消息，consumer拉取消息

rocketmq-client：消息发送和接收，包含consumer和producer

rocketmq-common：通用的枚举、基类方法、或者数据结构，包名有admin、consumer、filter、hook、message

rocketmq-distribution：脚本、配置模块，RocketMQ编译时，bin目录，benchmark目录，conf目录都是从这个模块编译输出的

rocketmq-example：示例模块

rocketmq-filter：消息过滤器

rocketmq-logappender：日志

rocketmq-logging：日志

rocketmq-namesrv：NameServer，类似服务注册中心，broker在这里注册，consumer和producer在这里找到broker地址

rocketmq-openmessaging：RocketMQ支持openmessaging，详见：http://openmessaging.cloud

rocketmq-remoting：使用netty的客户端、服务端，使用fastjson序列化，自定义二进制协议

rocketmq-srvutil：只有一个ServerUtil类，只提供Server程序依赖，尽可能减少客户端依赖

rocketmq-store：消息存储，索引，consumerLog，commitLog等

rocketmq-tools：命令行工具