Broker模块划分

本篇在上一篇《消息中间件架构讨论》的基础上分析Broker的模块划分。

上图是之前讨论确定的系统架构(后续内容会按照这个架构来叙述),几点基础:

  1. Broker采用主从结构

  2. Broker负责持久化元数据并汇报到NameServer

  3. 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相关的技术文章,希望能和更多的朋友交流。

原文地址:https://www.cnblogs.com/hzmark/p/mq_broker_arch.html