验证：对一个真实运行中的broker做线程转储
命令 · shell $ jcmd <broker2的pid> Thread.print | grep -E "kafka-(network|request-handler)-thread"
验证：每个监听端口真实各有3个网络线程，对应num.network.threads=3
真实实测 · 本机执行输出
"data-plane-kafka-network-thread-2-PLAINTEXT-PLAINTEXT-0" ... "data-plane-kafka-network-thread-2-PLAINTEXT-PLAINTEXT-1" ... "data-plane-kafka-network-thread-2-PLAINTEXT-PLAINTEXT-2" ... "data-plane-kafka-network-thread-2-CONTROLLER-PLAINTEXT-0" ... "data-plane-kafka-network-thread-2-CONTROLLER-PLAINTEXT-1" ... "data-plane-kafka-network-thread-2-CONTROLLER-PLAINTEXT-2" ...
这台broker2真实同时开着两个监听端口——真实对外的PLAINTEXT数据端口，和真实给controller quorum内部通信用的CONTROLLER端口。每个端口真实各分到了3个网络线程(编号0/1/2)，跟server.properties里配的num.network.threads=3正好对上——这个参数真实控制的是"每一个监听端口配几个线程"，不是全局共用3个，两个端口加起来这台broker真实一共跑着6个网络线程。
验证：请求处理线程真实是另外一拨，跟网络线程数量不一样
真实实测 · 本机执行输出
"data-plane-kafka-request-handler-0" ... "data-plane-kafka-request-handler-1" ... "data-plane-kafka-request-handler-2" ... "data-plane-kafka-request-handler-3" ... "data-plane-kafka-request-handler-4" ... "data-plane-kafka-request-handler-5" ... "data-plane-kafka-request-handler-6" ... "data-plane-kafka-request-handler-7" ...
真实数出8个request-handler线程，跟num.io.threads=8对上，而且不管来自PLAINTEXT端口还是CONTROLLER端口的请求，真实共用同一个8线程池，不像网络线程那样按端口各自分开。这揭示了Kafka处理一个请求真实的两段式结构：网络线程只负责最轻量的活——从socket读字节、按协议解析成请求对象、再把响应字节写回socket，真实不掺和任何业务逻辑；解析好的请求会被真实丢进一个共享队列，由request-handler线程池真实去处理业务逻辑（读写日志、更新offset、走ISR判断等等）。这样设计的好处是网络线程真实几乎不会被慢请求卡住——哪怕某个请求处理很慢，占用的是request-handler线程，网络线程依然能真实持续收发其它连接的字节，不会真实因为一个慢请求拖累了所有客户端的网络IO。
分步演示：一个broker进程里真实跑着哪些线程
每一步都是本文上面用jcmd Thread.print跑出来的原始结果。
网络线程按端口分开，请求处理线程全局共享
这一步新验证的线程组
参考与说明
- 数据来自本机3节点Kafka 4.3.1集群中的broker2(node.id=2)，用JDK自带的jcmd <pid> Thread.print做的真实线程转储。
- 没有验证：num.network.threads/num.io.threads真实调大调小之后对吞吐和延迟的影响；SSL/SASL这类需要额外握手开销的监听器上网络线程真实的负载差异。
下一篇 · KAFKA 内部原理 53
Kafka 为什么使用 NIO 和零拷贝
京公网安备11010502063487号