kafka請求全流程（三）—— I/O處理

承接上一篇，請求的接收與分發(https://blog.csdn.net/fenglei0415/article/details/106172921)，接下來應該是請求隊列的通道(https://blog.csdn.net/fenglei0415/article/details/105960812)。本篇是I/O的線程邏輯。

Broker端參數 num.io.threads 參數表示的就是 I/O 線程池的大小。所謂的 I/O 線程池，即 KafkaRequestHandlerPool，也稱請求處理線程池。

KafkaRequestHandlerPool

KafkaRequestHandlerPool 是真正處理 Kafka 請求的地方。它所在的文件是 KafkaRequestHandler.scala，位於 core 包的 src/main/scala/kafka/server 下。這是一個不到 400 行的小文件。

主要類如下：

KafkaRequestHandler：請求處理線程類。每個請求處理線程實例，負責從 SocketServer 的 RequestChannel 的請求隊列中獲取請求對象，並進行處理。
KafkaRequestHandlerPool：請求處理線程池，負責創建、維護、管理和銷燬下轄的請求處理線程。
BrokerTopicMetrics：Broker 端與主題相關的監控指標的管理類。
BrokerTopicStats（C）：定義 Broker 端與主題相關的監控指標的管理操作。
BrokerTopicStats（O）：BrokerTopicStats 的伴生對象類，定義 Broker 端與主題相關的監控指標，比如常見的 MessagesInPerSec 和 MessagesOutPerSec 等。

KafkaRequestHandler

// 關鍵字段說明
// id: I/O線程序號
// brokerId：所在Broker序號，即broker.id值
// totalHandlerThreads：I/O線程池大小
// requestChannel：請求處理通道
// apis：KafkaApis類，用於真正實現請求處理邏輯的類
class KafkaRequestHandler(
  id: Int,
  brokerId: Int,
  val aggregateIdleMeter: Meter,
  val totalHandlerThreads: AtomicInteger,
  val requestChannel: RequestChannel,
  apis: KafkaApis,
  time: Time) extends Runnable with Logging {
  ......
}

從定義可知，KafkaRequestHandler 是一個 Runnable 對象，因此，你可以把它當成是一個線程。每個 KafkaRequestHandler 實例，都有 4 個關鍵的屬性。

id：請求處理線程的序號，類似於 Processor 線程的 ID 序號，僅僅用於標識這是線程池中的第幾個線程。
brokerId：Broker 序號，用於標識這是哪個 Broker 上的請求處理線程。
requestChannel：SocketServer 中的請求通道對象。KafkaRequestHandler 對象爲什麼要定義這個字段呢？我們說過，它是負責處理請求的類，那請求保存在什麼地方呢？實際上，請求恰恰是保存在 RequestChannel 中的請求隊列中，因此，Kafka 在構造 KafkaRequestHandler 實例時，必須關聯 SocketServer 組件中的 RequestChannel 實例，也就是說，要讓 I/O 線程能夠找到請求被保存的地方。
apis：這是一個 KafkaApis 類。如果說 KafkaRequestHandler 是真正處理請求的，那麼，KafkaApis 類就是真正執行請求處理邏輯的地方。

既然 KafkaRequestHandler 是一個線程類，那麼，除去常規的 close、stop、initiateShutdown 和 awaitShutdown 方法，最重要的當屬 run 方法實現了，如下所示：

def run(): Unit = {
  // 只要該線程尚未關閉，循環運行處理邏輯
  while (!stopped) {
    val startSelectTime = time.nanoseconds
    // 從請求隊列中獲取下一個待處理的請求
    val req = requestChannel.receiveRequest(300)
    val endTime = time.nanoseconds
    // 統計線程空閒時間
    val idleTime = endTime - startSelectTime
    // 更新線程空閒百分比指標
    aggregateIdleMeter.mark(idleTime / totalHandlerThreads.get)
    req match {
      // 關閉線程請求
      case RequestChannel.ShutdownRequest =>
        debug(s"Kafka request handler $id on broker $brokerId received shut down command")
        // 關閉線程
        shutdownComplete.countDown()
        return
      // 普通請求
      case request: RequestChannel.Request =>
        try {
          request.requestDequeueTimeNanos = endTime
          trace(s"Kafka request handler $id on broker $brokerId handling request $request")
          // 由KafkaApis.handle方法執行相應處理邏輯
          apis.handle(request)
        } catch {
          // 如果出現嚴重錯誤，立即關閉線程
          case e: FatalExitError =>
            shutdownComplete.countDown()
            Exit.exit(e.statusCode)
          // 如果是普通異常，記錄錯誤日誌
          case e: Throwable => error("Exception when handling request", e)
        } finally {
          // 釋放請求對象佔用的內存緩衝區資源
          request.releaseBuffer()
        }
      case null => // 繼續
    }
  }
  shutdownComplete.countDown()
}

解釋下 run 方法的主要運行邏輯。它的所有執行邏輯都在 while 循環之下，因此，只要標誌線程關閉狀態的 stopped 爲 false，run 方法將一直循環執行 while 下的語句。

第 1 步是從請求隊列中獲取下一個待處理的請求，同時更新一些相關的統計指標。如果本次循環沒取到，那麼本輪循環結束，進入到下一輪。如果是 ShutdownRequest 請求，則說明該 Broker 發起了關閉操作。

而 Broker 關閉時會調用 KafkaRequestHandler 的 shutdown 方法，進而調用 initiateShutdown 方法，以及 RequestChannel 的 sendShutdownRequest 方法，而後者就是將 ShutdownRequest 寫入到請求隊列。

一旦從請求隊列中獲取到 ShutdownRequest，run 方法代碼會調用 shutdownComplete 的 countDown 方法，正式完成對 KafkaRequestHandler 線程的關閉操作。你看看 KafkaRequestHandlerPool 的 shutdown 方法代碼，就能明白這是怎麼回事了。

def shutdown(): Unit = synchronized {
    info("shutting down")
    for (handler <- runnables)
      handler.initiateShutdown() // 調用initiateShutdown方法發起關閉
    for (handler <- runnables)
      // 調用awaitShutdown方法等待關閉完成
      // run方法一旦調用countDown方法，這裏將解除等待狀態
      handler.awaitShutdown() 
    info("shut down completely")
  }

一旦 run 方法執行了 countDown 方法，程序流解除在 awaitShutdown 方法這裏的等待，從而完成整個線程的關閉操作。

如果從請求隊列中獲取的是普通請求（非shutdown請求），那麼，首先更新請求移出隊列的時間戳，然後交由 KafkaApis 的 handle 方法執行實際的請求處理邏輯代碼。待請求處理完成，並被釋放緩衝區資源後，代碼進入到下一輪循環，周而復始地執行以上所說的邏輯。

KafkaRequestHandlerPool

KafkaRequestHandlerPool 線程池的實現。它是管理 I/O 線程池的，實現邏輯也不復雜。重點看下，它是如何創建這些線程的，以及創建它們的時機。

// 關鍵字段說明
// brokerId：所屬Broker的序號，即broker.id值
// requestChannel：SocketServer組件下的RequestChannel對象
// api：KafkaApis類，實際請求處理邏輯類
// numThreads：I/O線程池初始大小
class KafkaRequestHandlerPool(
  val brokerId: Int, 
  val requestChannel: RequestChannel,
  val apis: KafkaApis,
  time: Time,
  numThreads: Int,
  requestHandlerAvgIdleMetricName: String,
  logAndThreadNamePrefix : String) 
  extends Logging with KafkaMetricsGroup {
  // I/O線程池大小
  private val threadPoolSize: AtomicInteger = new AtomicInteger(numThreads)
  // I/O線程池
  val runnables = new mutable.ArrayBuffer[KafkaRequestHandler](numThreads)
  ......
}

KafkaRequestHandlerPool 對象定義了 7 個屬性，其中比較關鍵的有 4 個，分別來解釋下。

brokerId：和 KafkaRequestHandler 中的一樣，保存 Broker 的序號。
requestChannel：SocketServer 的請求處理通道，它下轄的請求隊列爲所有 I/O 線程所共享。requestChannel 字段也是 KafkaRequestHandler 類的一個重要屬性。
apis：KafkaApis 實例，執行實際的請求處理邏輯。它同時也是 KafkaRequestHandler 類的一個重要屬性。
numThreads：線程池中的初始線程數量。它是 Broker 端參數 num.io.threads 的值。目前，Kafka 支持動態修改 I/O 線程池的大小，因此，這裏的 numThreads 是初始線程數，調整後的 I/O 線程池的實際大小可以和 numThreads 不一致。

I/O 線程池的大小是可以修改的。如果你查看 KafkaServer.scala 中的 startup 方法：

// KafkaServer.scala
dataPlaneRequestHandlerPool = new KafkaRequestHandlerPool(config.brokerId, socketServer.dataPlaneRequestChannel, dataPlaneRequestProcessor, time, config.numIoThreads, s"${SocketServer.DataPlaneMetricPrefix}RequestHandlerAvgIdlePercent", SocketServer.DataPlaneThreadPrefix)

controlPlaneRequestHandlerPool = new KafkaRequestHandlerPool(config.brokerId, socketServer.controlPlaneRequestChannelOpt.get, controlPlaneRequestProcessor, time, 1, s"${SocketServer.ControlPlaneMetricPrefix}RequestHandlerAvgIdlePercent", SocketServer.ControlPlaneThreadPrefix)

由代碼可知，Data plane 所屬的 KafkaRequestHandlerPool 線程池的初始數量，就是 Broker 端的參數 nums.io.threads，即這裏的 config.numIoThreads 值；而用於 Control plane 的線程池的數量，則硬編碼爲 1。

你可以發現，Broker 端參數 num.io.threads 的值控制的是 Broker 啓動時 KafkaRequestHandler 線程的數量。因此，當你想要在一開始就提升 Broker 端請求處理能力的時候，不妨試着增加這個參數值。

是管理 I/O 線程池的類，KafkaRequestHandlerPool 中最重要的字段當屬線程池字段 runnables 了。就代碼而言，Kafka 選擇使用 Scala 的數組對象類實現 I/O 線程池。

createHandler 方法

當線程池初始化時，Kafka 使用下面這段代碼批量創建線程，並將它們添加到線程池中：

for (i <- 0 until numThreads) {
  createHandler(i) // 創建numThreads個I/O線程
}
// 創建序號爲指定id的I/O線程對象，並啓動該線程
def createHandler(id: Int): Unit = synchronized {
  // 創建KafkaRequestHandler實例並加入到runnables中
  runnables += new KafkaRequestHandler(id, brokerId, aggregateIdleMeter, threadPoolSize, requestChannel, apis, time)
  // 啓動KafkaRequestHandler線程
  KafkaThread.daemon(logAndThreadNamePrefix + "-kafka-request-handler-" + id, runnables(id)).start()
}

源碼使用 for 循環批量調用 createHandler 方法，創建多個 I/O 線程。createHandler 方法的主體邏輯分爲三步：

創建 KafkaRequestHandler 實例；
將創建的線程實例加入到線程池數組；
啓動該線程。

resizeThreadPool 方法

這個方法的目的是，把 I/O 線程池的線程數重設爲指定的數值。代碼如下：

def resizeThreadPool(newSize: Int): Unit = synchronized {
  val currentSize = threadPoolSize.get
  info(s"Resizing request handler thread pool size from $currentSize to $newSize")
  if (newSize > currentSize) {
    for (i <- currentSize until newSize) {
      createHandler(i)
    }
  } else if (newSize < currentSize) {
    for (i <- 1 to (currentSize - newSize)) {
      runnables.remove(currentSize - i).stop()
    }
  }
  threadPoolSize.set(newSize)
}

該方法首先獲取當前線程數量。如果目標數量比當前數量大，就利用剛纔說到的 createHandler 方法將線程數補齊到目標值 newSize；否則的話，就將多餘的線程從線程池中移除，並停止它們。最後，把標識線程數量的變量 threadPoolSize 的值調整爲目標值 newSize。

KafkaRequestHandlerPool 類的 3 個重要方法 shutdown、createHandler 和 resizeThreadPool 就分析完了。總體而言，它就是負責管理 I/O 線程池的類。

下一篇就是分析下KafkaRequestHandler 線程如何將 Response 放入 Processor 線程的 Response 隊列。也就是KafakApis類de用途。

kafka請求全流程（三）—— I/O處理

KafkaRequestHandlerPool

KafkaRequestHandler

KafkaRequestHandlerPool

createHandler 方法

resizeThreadPool 方法

Tornado之源碼解析

kafka日誌對象（三）—— Log的操作

kafka日誌對象（一）—— Log Segment

kafka日誌對象（二）—— Log

kafka請求全流程(二)——請求的接收以及分發

Mac下配置sublime實現LaTeX

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結