【kafka4源码学习系列】kafka4总体架构介绍

二 kafka架构介绍

学习一个系统之前很重要的一点就是先了解这个系统整体的架构，这能够使我们对整个系统有个总体的认识，清楚地知道这个系统有什么能力。这不仅帮助我们学习时快速定位到我们想要的内容，还能避免我们学习过程中在庞大的系统中迷失自己。所以首先我会介绍一下kafka的整体架构，包括这个kafka系统的整体架构，模块组成，模块的功能以及模块之间关系，以及各个模块之间是怎么共同构成这套系统的。kafka官方并不直接提供他们源码的架构图，模块功能和边界，所以这块的内容是我根据kafka各模块的功能，依赖关系自己组织起来的，并且对各模块做了分层方便我们学习。

2.1 kafka架构和模块

kafka4整体由21个模块组成，但是kafka并不像spring那样采用严格的分层架构，模块的划分设计主要还是为了尽可能复用代码并且避免模块直接引入其他不需要的代码，然后很多kafka官方工具和客户端/API的源码也会放在单独的模块中管理。这里我们文章关心的主要kafka broker相关的源码。对于客户端，工具等的代码不会做太多介绍。但是也有必要做一些简单介绍提升我们对于kafka的整体认知，下面简单贴一下kafka4.1的源码，里面就能够清楚地看到我们下面会说地21个模块了。

尽管kafka没有严格地对模块进行分层，这里还是根据各个模块的功能和依赖关系对各个模块进行了归类和分层。以下就是kafka的架构图。

首先最底层的通用模块就是server-common了，这个模块主要负责定义kafka通用抽象，常量和封装公共方法等，kafka服务的其他模块都会依赖这个模块减少代码冗余，除此之外还有负责数据持久化的storage模块。为其他模块提供持久化数据的管理。

然后就是元数据于协调模块，这些模块主要封装了集群内各broker，组内各消费者，事务内各生产者和broker的行为协调逻辑，实现broker分区分配，消费者分区分配和kafka事务的功能，之所以吧元数据和协调放在同一层，是因为metadata模块既封装了元数据相关的管理操作，也实现了集群内broker的协调逻辑，同时其他协调器也会依赖metadata模块的元数据来完成自己的协调功能。如果单独划出元数据层的话，就会错误地忽略掉metadata模块对集群broker协调作用。同时coordinator-common和share-coordinator模块并不是独立的协调器实现，它们只是封装了协调器会用到的公共抽象和通用逻辑，减少代码冗余。与元数据于协调模块同层的就是负责实现kraft逻辑的raft模块了，其实我们也可以认为它也是一个协调模块，负责kraft集群内机器的协调管理。

再往上就是基础服务模块server了，很多可能被他的名字迷惑，觉得是在server里面完成的kafka broker的实现逻辑，其实这是错误的，server主要就是依赖于上面的模块实现了服务通用功能，这些功能并不是Kafka专有的，其他大多数服务都有这些功能，比如服务埋点和监控，配额管理，副本管理等，Kafka把这些逻辑抽离出到server模块上，让core模块能够专心实现Kafka核心的功能。

然后就到了我们的核心模块core了，它依赖其他模块实现了kafka的broker，存放broker的入口程序