本篇在上一篇《消息中间件架构讨论》的基础上分析Broker的模块划分。
上图是之前讨论确定的系统架构（后续内容会按照这个架构来叙述），几点基础：
Broker采用主从结构
Broker负责持久化元数据并汇报到NameServer
Client从NameServer获取元数据，然后从Broker读取消息
Broker的模块划分
1 网络模块
Broker需要和NameServer及Client通信，包括Broker之间也需要通信（主从结构），所以Broker会有一个模块（Net&PacketHandler）用于所有网络包的处理。
2 元数据相关
我们会将NameServer尽量做的简单，所以NameServer不会持久化任何数据。最终NameServer是无状态的，所有数据来源于Broker上报，所以元数据会持久化在Broker上。除了持久化Topic、Group这样的元数据，Broker还需要保存消费进度。
另外，为了保证分区内数据的顺序性，需要确保一个分区在一个时刻只会有一个线程来消费，所以Broker端需要提供接口对分区执行加锁操作。我们采用租约的方式来实现：Client需要对获取到分区的租约才能对分区进行消费。所以Broker会包含一个租约模块（Leaser）。
所以Broker元数据模块会包含以下几块：
TopicManager
GroupManager
CursorManager
Leaser
4 消息写入模块
消息从Client发送到Broker，Broker接收到消息后会增强消息属性，比如给消息添加索引位置、存储位置、存储时间等属性，然后进行持久化。所以Broker端会有一个模块处理写入请求（Writer）。
5 消息读取模块
Broker需要将持久化的消息读取出来返回给客户端，且持久化WAL是多个Topic共享的，所以需要一个独立的读取模块（Reader）的从WAL的不同位置读取数据拼装成最终的结果返回给客户端。
6 存储模块
最终所有消息是要落盘的，所以Broker肯定包含了一个存储模块。存储模块使用WAL的方式实现，分为两块：存储队列和索引队列，消息会被写入到存储队列，然后构建索引，这块内容会在之后的Broker实现部分详细介绍。
（存储模块应该是整个消息中间件中最复杂的模块，本篇没有展现介绍，会在介绍系统具体实现时详细的描述整个存储层的实现）
除了以上这些模块外，Broker采用主从架构，必然会有负责主从复制的模块，还包括元数据的备份策略（元数据也是需要有多个备份的）。除此之外可能还有监控统计模块，用于监测系统状态，但这不在我们讨论的范围。
总结以上内容，Broker的模块大致如下：
结语
本篇内容主要是简单的介绍一下Broker内部模块的划分。按照计划，后续两篇内容应该分别是《NameServer模块分析》、《Client模块分析》，之后是开始进入详细设计的阶段，会开始定义各个实体及协议。
欢迎关注此公众号，将坚持不懈的写MQ相关的技术文章，希望能和更多的朋友交流。
