Kafka

Kafka 网络模型

·6 分钟阅读·2320 字
kafkanetworkperformancearchitecture

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

📋 目录

Kafka 网络模型

Kafka 基于 Reactor 多线程的网络模型——Acceptor → Processor → Handler 三层架构。

Kafka 网络模型一句话总结：Broker 端自研 Java NIO + 多 Reactor 线程模型，核心是 1 Acceptor + N Processor + M Handler，把“建连接、收/发网络包、业务处理”三层彻底解耦，做到高吞吐、低延迟、高并发。

一、整体架构（SocketServer）

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

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

1）Acceptor 线程（单线程）

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

2）Processor 线程池（N 个，可配置）

参数：num.network.threads，默认 3
每个 Processor 拥有独立 Selector，职责：

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

3）Handler 线程池（M 个，可配置）

参数：num.io.threads，默认 8
真正干活的线程池（KafkaRequestHandlerPool）：

  • 从 Processor 的 RequestQueue 取请求

  • 调用 KafkaApis 处理业务：

  • 生产：追加到日志、更新索引

  • 消费：从日志读取、返回数据

  • 元数据：Leader 选举、ISR 管理

  • 处理完生成 Response，放回 Processor 的 ResponseQueue

二、请求全流程（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 写给客户端

三、核心设计亮点（为什么快）

1）Reactor 多线程解耦

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

2）RequestChannel 无锁队列

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

3）IO 线程与网络线程分离

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

4）协议优化

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

四、关键参数（生产调优必懂）

## 网络线程数（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

五、对比传统模型（为什么 Kafka 不用 BIO）

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

六、一句话背下来

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

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

关联文档

返回首页订阅更新