Kafka

Kafka 网络模型

·6 分钟阅读·2147 字

Kafka SocketServer 架构——Acceptor、Processor、Handler 线程模型与 Reactor 模式

📋 目录

Kafka 网络模型

1. 整体架构(SocketServer)

Kafka 不依赖 Netty,自己封装 NIO,核心入口是 SocketServer。
三层结构:

  • Acceptor(1 个):监听端口、接受 TCP 连接
  • Processor(N 个):NIO Selector,负责读写网络数据
  • Handler(M 个):执行业务逻辑(写日志、读消息、副本同步等)

1.1. Acceptor 线程(单线程)

  • 绑定端口(默认 9092),ServerSocketChannel 注册到自己的 Selector
  • 只做一件事:接受新连接 → 生成 SocketChannel → 轮询分给某个 Processor
  • 连接分配:简单轮询,保证负载均衡

1.2. Processor 线程池(N 个,可配置)

参数:num.network.threads,默认 3

每个 Processor 拥有独立 Selector,职责:

  • 读事件:从 SocketChannel 读取字节 → 解析 Kafka 协议 → 生成 Request 对象
  • 写事件:Handler 处理完后,把 Response 写回客户端
  • 内部队列:每个 Processor 有一个 RequestChannel(RequestQueue + ResponseQueue),解耦网络 I/O 与业务处理

1.3. Handler 线程池(M 个,可配置)

参数:num.io.threads,默认 8

真正干活的线程池(KafkaRequestHandlerPool):

  • 从 Processor 的 RequestQueue 取请求
  • 调用 KafkaApis 处理业务:
  • 生产:追加到日志、更新索引
  • 消费:从日志读取、返回数据
  • 元数据:Leader 选举、ISR 管理
  • 处理完生成 Response,放回 Processor 的 ResponseQueue

2. 请求全流程(6 步走)

  1. Acceptor 接收连接:客户端发起 TCP → Acceptor 接受 → 分给 Processor
  2. Processor 读取请求:Selector 检测读事件 → 读取字节 → 解析协议 → Request
  3. 入队 RequestQueue:Processor 把 Request 放入自己的 RequestChannel
  4. Handler 处理业务:Handler 线程从队列取 Request → KafkaApis 处理 → Response
  5. 入队 ResponseQueue:Response 放回原 Processor 的 ResponseQueue
  6. Processor 写回响应:Selector 检测写事件 → 把 Response 写给客户端

3. 核心设计亮点(为什么快)

3.1. Reactor 多线程解耦

  • Acceptor(连接)→ Processor(I/O)→ Handler(业务) 完全分离
  • 互不阻塞:连接、读写、业务处理并行,无瓶颈
  • 线程复用:NIO 非阻塞,一个线程管理多个连接

3.2. RequestChannel 无锁队列

  • 每个 Processor 独立队列,无锁设计,并发性能极高
  • 避免多线程竞争,吞吐量可达百万级

3.3. IO 线程与网络线程分离

  • num.network.threads:处理网络读写(轻量)
  • num.io.threads:处理磁盘 I/O、日志读写(重度)
  • 可独立调优:网络密集调大前者,磁盘密集调大后者

3.4. 协议优化

  • 自定义二进制协议,紧凑高效
  • 批量压缩:支持 Snappy、LZ4、GZIP,减少网络传输量

4. 关键参数(生产调优必懂)


## 网络线程数(Processor):处理连接、读写

num.network.threads=3

### IO 线程数(Handler):处理磁盘、业务

num.io.threads=8##

## 每个 Processor 的队列大小(最大等待请求数)

queued.max.requests=50##

## Socket 发送/接收缓冲区

socket.send.buffer.bytes=102400

socket.receive.buffer.bytes=102400

5. 对比传统模型(为什么 Kafka 不用 BIO)

  • BIO(1 连接 1 线程):连接多 → 线程爆炸 → 内存耗尽 → 宕机
  • 单 Reactor(1 线程处理所有 I/O):单核瓶颈,无法利用多核
  • Kafka 多 Reactor:Acceptor 分连接 → 多 Processor 并行 I/O → 多 Handler 并行业务,多核拉满、吞吐拉满

6. 一句话背下来

1 个 Acceptor 接连接,N 个 Processor 做读写,M 个 Handler 干业务,全程 NIO 非阻塞、队列解耦、线程隔离,高吞吐低延迟。

要不要我把这个网络模型和你之前问的 Ansible 结合,写一个“一键部署 Kafka 并调优网络参数”的完整 Role 示例?


关联文档

Yanche Blog

记录云原生、Linux、数据库等技术领域的学习心得,以及日常生活的思考与感悟。

© 2026 Yanche Blog. All rights reserved.

Powered by Astro