Kafka源码分析（十五）——Broker：网络层——Processor线程

码炫课堂-码哥

于 2024-06-08 16:39:37 发布

阅读量985

点赞数 22

CC 4.0 BY-SA版权

分类专栏： kafka专题文章标签： kafka 分布式

本文链接：https://blog.youkuaiyun.com/smart_an/article/details/139548202

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

 阶段2、深入多线程设计模式

 阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

上一章讲到，Acceptor线程通过创建SocketChannel与客户端完成三次握手，建立TCP连接后，会将SocketChannel交给Processor线程处理。本章，我们就来看看Processor线程内部的运行机制。

一、整体架构

Processer线程的数量是通过num.network.threads配置的，默认3个，即一个Acceptor线程对应3个Processor线程。Processor会对读/写请求进行处理，我后面会分两部分分别讲解读/写流程，这样流程会更清晰，也便于读者理解，我们先来看Processer线程的整体工作流程。

1.1 工作流程

Acceptor线程通过调用Processor.accept()方法，将SocketChannel交给Processor线程处理：Processor线程会把SocketChannel放到自己内部的一个 ConcurrentLinkedQueue 队列中：

    // Processor.scala
    
    private val newConnections = new ConcurrentLinkedQueue[SocketChannel]()
    def accept(socketChannel: SocketChannel) {
        // 1.将已经建立连接的SocketChannel加入到Processor内部的队列
        newConnections.add(socketChannel)
        // 2.唤醒Processor线程
        wakeup()
    }

Processor线程在运行过程中，会按照以下的流程进行处理：

首先，从内部队列的队首取出一个SocketChannel；
接着，利用Processor自身的Selector，在SocketChannel上配置连接，并注册对OP_READ读事件的监听；
然后，从RequestChannel组件的响应队列中获取一个Response对象，缓存到KafkaChannel中，同时增加对OP_WRITE事件的监听；
接着，通过Selector轮询SelectionKey，如果有OP_READ/OP_WRITE事件发生，就进行相应的读写操作；
最后，对断开的连接进行处理。

    // Processor.scala
    
    override def run() {
      while (isRunning) {
        try {
          // 1.从队列获取SocketChannel，配置连接，监听OP_READ事件
          configureNewConnections()
          // 2.从RequestChannel的响应队列中获取Response对象，设置到对应的KafkaChannel，同时增加对OP_WRITE事件的监听
          processNewResponses()
          // 3.轮询处理读请求/写响应，封装/解析底层字节流
          poll()
          // 4.发送封装后的读请求
          processCompletedReceives()
          // 5.发送解析完的写响应
          processCompletedSends()
          // 6.处理断开连接
          processDisconnected()
        } catch {
          case e: ControlThrowable => throw e
          case e: Throwable =>
            error("Processor got uncaught exception.", e)
        }
      }
      debug("Closing selector - processor " + id)
      swallowError(closeAll())
      shutdownComplete()
    }

可以看到，上述整个流程和我之前讲解的Kafka客户端的NIO处理流程比较相似，核心的NIO处理流程就是在上面这个循环中完成的。