去年自己在工作中接触了 Kafka，然后写了篇网络层的源码分析(应该叫源码注释 + 画图) https://mp.weixin.qq.com/s/-VzDU0V8J2guNXwhiBEEyg

Request队列线程共享，这样不同线程的workload才不会发生倾斜，不然可能会发生一边的线程空闲，一边的线程队列满

课后题思考： （1）Request 队列在被 IO 线程取走处理时不需要关心 Request 被哪个 IO 线程处理了。处理完放入到对应的 Response 队列就好。 （2）Response 队列是线程私有的，因为 Processor 管理着某一组 SocketChannel，SocketChannel 发出的某个 Request 处理完成后生成 Response 还需要在该 Processor Send 出去。 （3）如果 Response 设计成跟 Request 一样在共享队列中， Processor 需要主动去 take 出来，这时还需要判定对应的 SocketChannel 是否属于这个 Processor。 或者设计成 由一个专门的线程取分发给不同的 Processor。那还不如 IO 线程处理完直接发给不同的 Response 队列划算也没有锁的竞争。 表达的核心逻辑就是 ：Processor 线程的 selector 注册了该线程所管理的一组 SocketChannel，收发请求只能由该 Processor 处理。所以由 Processor 管理独属的 Response 队列。

老师，想请教一个问题，kafka是如何处理nio 的 epoll空轮训bug的？

老师你好，我这边生产环境kafka0.10版本生产者偶然会出现kafka.common.FailedToSendMessageException: Failed to send messages after 3 tries的问题，问一下您这边有什么好的定位思路吗？

为什么Clients 与 Broker 的通信网络延迟很大，建议调大缓冲区呢？背后原理是什么？

老师您好，看过这块的网络模型后是不是可以理解为kafka的broker端采用的是reactor中的多线程模型，也就是说一个reactor负责网络上的链接，接收等操作，处理资源池是多个，负责读数据，处理业务(这里也就是放在队列里)，这样理解对吗

老版本的response Queue好像确实是保存在requestChannel中，用processor id去索引的

文中说: 每当 Processor 线程接收新的连接请求时，都会将对应的 SocketChannel 放入这个队列。后面在创建连接时（也就是调用 configureNewConnections 时），就从该队列中取出 SocketChannel，然后注册新的连接。 按照我的理解, tcp 三次握手是在 Acceptor 调用 accept() 完成之前就已经完成了的. 而并不是 processor 的工作. processor 的 configureNewConnections 方法只是将 已经建立的连接取出来再次注册 OP_READ 事件而已 老师怎么看? 大家有什么想法么?