该组件的核心就是一个Raft协议的实现。这个Raft协议的实现用的也不是淘宝系的JRaft，而是第三方的产品DLedger。对于生产要求比较严格的大厂，这个倒是比较意外。

用这个组件一般就是用来实现选主，或者当一个存储数据库来使用。前几篇有说过RocketMQ使用ControllerManager组件来实现的灾备切换，那么我们来看一下究竟是如何实现的。

对外接口

ControllerRequestProcessor

名称	描述	Raft操作类型
CONTROLLER_ALTER_SYNC_STATE_SET	往Raft日志同步syncStateSet	写
CONTROLLER_ELECT_MASTER	进行leader选举，将最终选出的Leader同步到Raft日志。让人震惊的是选主没有使用到Raft，而是自己实现的策略。	写
CONTROLLER_GET_REPLICA_INFO	按照brokerName获取所有broker信息	读
CONTROLLER_GET_METADATA_INFO	获取当前Raft集群所有Peer信息	读
BROKER_HEARTBEAT	Broker进行心跳	无
CONTROLLER_GET_SYNC_STATE_DATA	获取syncStateSet数据	读
UPDATE_CONTROLLER_CONFIG	更新ControllerManager配置	无
GET_CONTROLLER_CONFIG	读取ControllerManager配置	无
CLEAN_BROKER_DATA	清理Broker数据	写
CONTROLLER_GET_NEXT_BROKER_ID	获取下一个BrokerId	读
CONTROLLER_APPLY_BROKER_ID	写入BrokerId	写
CONTROLLER_REGISTER_BROKER	使用唯一的BrokerId注册Broker	写

启动过程

NameServer模块下的代码结构，项目启动类为NamesrvStartup。启动过程主要做了如下几件事情。

1. 读取配置文件和命令行参数
2. 初始化并启动netty服务端和netty客户端
3. 初始化并启动NamesrvController，注册processor，提供对外接口

代码目录结构

对外接口

processor目录下则为主要的对外接口。通过梳理NameServer的接口，以了解更多的功能细节。

Read More

我选择的源码版本是5.1.4 源码地址来进行学习，如下是来自官方的架构图

按照5.0弹性无状态代理模式的架构图，我们可以将RocketMQ 分为如下主要模块：

1. Console/MqAdmin

2. Proxy

3. Broker （local模式下与Proxy部署在同一个进程，cluster模式下和Proxy分为两个进程部署）

4. NameServer

5. Controller（ControllerManager） 可以和NameServer部署在同一个进程

该组件使得RocketMQ具有，主备自动切换的能力。

6.各种语言的Client

各个组件的功能作用，后面再一个个分析和解释。但我想有些中间件和架构爱好者看这个图，就能大概知道各个组件有啥用途。

最近上班比较清闲，之前一直在微信读书上读了不少闲书。颇有游手好闲，不务正业的样子。最近内心思索半天，觉得这样下去自己的职业生涯可能走不远。又由于最近公司在考虑消息队列的选型，所以想着花点时间去深入了解一下消息队列的机制。一方面是对RocketMQ比较感兴趣；另一方面也是希望对所学的技术做一个记录，将来出去面试，作为展示自我技术学习成果的窗口。

为什么选择RocketMQ？

Java 事务消息 社区活跃 支撑阿里的业务

我准备带着一些问题去进行阅读，相比于一头扎进代码海洋，这样更有针对性，并且收获可能更大。这样的一个大型开源产品，不去看一些细枝末节的细节，可能更有效率，也更节约时间。

带着哪些问题去看？

1、NameServer服务注册机制？

2、消息底层文件存储机制？

3、定时消息实现机制？

4、顺序消息实现机制？

5、事务型消息实现机制？

6、高可用、故障转移机制？