broker网络通信模型
- Clients 或其他 Broker 发送请求给 Acceptor 线程
- 2&3 Processor 线程处理请求，并放入请求队列
- I/O 线程处理请求
- KafkaRequestHandler 线程将 Response 放入 Processor 线程的 Response 队列（每个Processor线程有自己的responseQueue）
- Processor 线程发送 Response 给 Request 发送方
下面引用 Kafka 2.8.0 源码里 SocketServer 类中一段很关键的注释：
Kafka 采用的是：很典型的 Reactor 网络通信模型,通俗点记忆就是1+N+M:
1：表示 1 个 Acceptor 线程，负责监听新的连接，然后将新连接交给 Processor 线程处理。
N：表示 N 个 Processor 线程，每个 Processor 都有自己的 selector，负责从 socket 中读写数据。
M：表示 M 个 KafkaRequestHandler 业务处理线程，它通过调用 KafkaApis 进行业务处理，然后生成 response，再交由给 Processor 线程。
请求在kafka broker的处理时间
当一个Kafka的Producer或Consumer请求进入到Kafka-Broker时，Processor组件将请求写入RequestQueue，RequestHandler从RequestQueue拉取请求进行处理，在RequestQueue中的等待时间是RequestQueueTime，RequestHandler具体的执行时间是LocalTime。当RequestHandler执行完毕后会将请求传递给DelayedPurgatory组件中，该组件是一个延时队列（比如ack=all 等待所有副本写入）。
当触发某一个延时条件完成了以后会把请求写到ResponseQueue中，在DelayedPurgatory队列持续的时间为RemoteTime，Processor会不断的从ResponseQueue中将数据拉取出来发往客户端，标红的ResponseTime是可能会被客户端影响的，因为如果客户端接收能力不足，那么ResponseTime就会一直持续增加。从Kafka-Broker的视角，每一次请求总的耗时是RequestTotalTime，包含了刚才所有流程分阶段计时总和。
jdq4的broker监控
RequestQueueSize、ResponseQueueSize、ProduceTotalTimeMsTP99、TCP链接等监控指标
参数调整
网络线程：num.network.threads
I/O 线程（请求处理线程池）：num.io.threads
