kafka服务端架构总览

发布于:2025-09-02 ⋅ 阅读:(16) ⋅ 点赞:(0)

Kafka系列文章

基于Kafka2.1解读Producer原理
基于Kafka2.1解读Consumer原理
Kafka服务端NIO操作原理解析(一)
Kafka服务端NIO操作原理解析(二)



前言

kafka服务端,咱们前两篇文章都是围绕kafka的IO进行分析的,读者很难有全貌的理解,也就是整个服务端有哪些功能,以及这些功能之间是如何协作。


一、kafka服务端的架构

1.1 基本概念介绍

其实任何一个系统,总结起来无非都是『计算』+『IO』。只不过针对咱们的平时的业务系统,“计算”比较多,也就是主要是业务逻辑;IO一般涉及到的是RPC服务框架的调用,当然不管是调用其他业务服务、中间件、数据源其实都是RPC,只不过可能是不同的“网络模型+自定义协议”。

1.2 kafka的特性

kafka作为一个开源的MQ框架,当然也是『计算』+『IO』,但是最为人称道的其实就是他的“IO”模型:网络IO+文件IO。
不过kafka还有个厉害的地方,他使用了计算和IO分离的模式。想想咱们自己的业务系统,是不是会写一段IO,写一段业务逻辑,来回穿插?而再回顾下Kafka服务端NIO操作原理解析(一)
Kafka服务端NIO操作原理解析(二),想想kafka服务端是怎么做的?几乎这两段全是数据的IO逻辑,也就是读取request,写入response的过程。根本不依赖于所谓的逻辑计算,也就是咱们kafka对producer和consumer的请求逻辑实际处理逻辑。
其实想想producer是不是也是这么干的?accumulator不停把数据组装成batches,Sender线程不停遍历batches,然后进行消息发送。producer通过batches,将accumulator和Sender解耦了。

二、kafkaServer

跟kafkaProducer一样,server端也有个主要的类,kafkaServer,不管是IO还是计算的动作都是它的属性的功能
kafkaServer的基本架构

2.1 服务端IO

服务端IO,其实处理的就是两件事:

  1. producer、consumer、follower replica发过来的request,进行封装,放到RequestChannel里,
  2. Processor从自己的responseQueue中获取response,然后通过网络IO写出去
    具体见Kafka服务端NIO操作原理解析(一)
    Kafka服务端NIO操作原理解析(二)

2.服务端计算

通过阅读服务端IO就会发现,貌似缺失了一环。

  1. 放到RequestChannel里的request被谁处理了?
  2. Processor的responseQueue里的response哪来的?

其实我们可以发现KafkaServer上还有个重要的属性,dataPlaneRequestHandlerPool,顾名思义,requestHandlerPool,那就是个运行池,该运行池的作用其实就是 handle request的。
requestHandlerPool示意图

2.3 计算和IO分离

其实分离、或者说解耦是咱们软件行业特别重要的一个特性以及思想。
服务端通过RequestChannel和Processor的responseQueue,将计算和IO进行了接口;producer呢?通过accumulator的topicInfoMap(其实就是batches)进行解耦

总结

着重介绍了下计算和IO分离思想在kafka设计中的实践,准备下一篇文章带出计算的具体逻辑


网站公告

今日签到

点亮在社区的每一天
去签到