RocketMQ源码 目录结构介绍

源码 GitHub地址:https://github.com/apache/rocketmq

前言

最近在看RocketMQ原理,不得不说,值得夸赞的地方还挺多的

1.RocketMQ的源码是Java,相比RabbitMQ(erlang)、kafka(scala),更易于通过源码了解其工作原理,虽然其他语言并不是障碍,但还是更习惯Java

2.docs 目录下有优秀的开发者指南,便于学习理解

在这里插入图片描述

源码目录

acl 权限模块

ACL是access control list的简称,访问控制列表

broker broker模块

启动类为BrokerStartup

Broker主要负责消息的存储、投递和查询以及服务高可用保证,为了实现这些功能,Broker包含了以下几个重要子模块。

  1. Remoting Module:整个Broker的实体,负责处理来自clients端的请求。
  2. Client Manager:负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息
  3. Store Service:提供方便简单的API接口处理消息存储到物理硬盘和查询功能。
  4. HA Service:高可用服务,提供Master Broker 和 Slave Broker之间的数据同步功能。
  5. Index Service:根据特定的Message key对投递到Broker的消息进行索引服务,以提供消息的快速查询。

client 消息客户端

消息客户端,包含消息生产者、消息消费者相关类

common 公共包

公共包

dev 开发者信息(非源代码)

开发者信息,不是源代码,就一个py文件

distribution 部署脚本、配置模块(非源代码)

docs 开发者文档(非源代码)

开发者文档,中英文双语

example 示例模块

RocketMQ 使用示例代码

filter 消息过滤器

消息过滤相关基础类

logappender 日志

日志相关类

logging 日志

日志相关类

namesrv NameServer模块

启动类为NamesrvStartup

NameServer是一个非常简单的Topic路由注册中心,其角色类似Dubbo中的zookeeper,支持Broker的动态注册与发现。主要包括两个功能:Broker管理,NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制,检查Broker是否还存活;路由信息管理,每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息,从而进行消息的投递和消费。NameServer通常也是集群的方式部署,各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息,所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了,Broker仍然可以向其它NameServer同步其路由信息,Producer,Consumer仍然可以动态感知Broker的路由的信息。

openmessaging 消息开放标准

消息开放标准

remoting 远程通信模块

远程通信模块

serutil 服务工具类

服务工具类

store 消息存储

消息存储实现相关类

style checkstyle&copyright 非源代码

checkstyle相关

test 测试相关

测试相关类

tool 命令行工具

工具类,监控命令相关实现类

部署启动流程

根据部署流程,深入学习源码细节是比较好的方式
在这里插入图片描述

  • 启动NameServer,NameServer起来后监听端口,等待Broker、Producer、Consumer连上来,相当于一个路由控制中心。
  • Broker启动,跟所有的NameServer保持长连接,定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后,NameServer集群中就有Topic跟Broker的映射关系。
  • 收发消息前,先创建Topic,创建Topic时需要指定该Topic要存储在哪些Broker上,也可以在发送消息时自动创建Topic。
  • Producer发送消息,启动时先跟NameServer集群中的其中一台建立长连接,并从NameServer中获取当前发送的Topic存在哪些Broker上,轮询从队列列表中选择一个队列,然后与队列所在的Broker建立长连接从而向Broker发消息。
  • Consumer跟Producer类似,跟其中一台NameServer建立长连接,获取当前订阅Topic存在哪些Broker上,然后直接跟Broker建立连接通道,开始消费消息。

猜你喜欢

转载自blog.csdn.net/weixin_43859729/article/details/112843796