# 請求處理 * Apache Kafka 自定義了一組請求協議 * 所有請求都是通過 TCP 以 Socket 的方式通訊 Kafka Broker 處理請求的全流程 * 順序處理請求 ``` Java while (true) { Request request = accept(connection); handle(request); } ``` * 缺陷：吞吐太差 --- * 每個請求使用單獨線程處理 ``` Java while (true) { Request = request = accept(connection); Thread thread = new Thread(() -> { handle(request);}); thread.start(); } ``` * 優點：吞吐大 * 缺點：資源開銷大 * 適合請求發送頻率低的場景 --- * Kafka 使用 Reactor 模式 Reactor 模式 * Reactor 模式是事件驅動架構的一種實現方式 * 適合應用于處理多個客戶端并發向服務器端發送請求的場景 * 參考：[http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf](http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf)  * 多個 Clients 發送請求到 Reactor * Reactor 的請求分發線程 Dispatcher，i.e. Acceptor 將不同的請求下發到多個 worker 線程中 * Acceptor 只涉及分發，因此有很高的吞吐 * Worker 線程根據業務需求可以任意增減，動態調節系統負載能力  * Kafka Broker 端參數 `num.network.threads` 調整網絡線程池的線程數，默認為 3 * Acceptor 線程通過輪詢方式將入站請求公平的發送到所有網絡線程中  * 當網絡線程拿到請求后，不是自己處理，而是放到一個共享請求隊列中 * Broker 端 IO 線程池負責從該隊列中取出請求，執行真正處理 * 如果是 Produce 請求，將消息寫入到底層的磁盤日志中 * 如果是 Fetch 請求，則從磁盤或頁緩存中讀取消息 * IO 線程池中的線程是執行請求邏輯的真正線程 * Broker 端參數 `num.io.threads` 控制了該線程池中的線程數，默認值為 8 * IO 線程處理完后，將 response 發送到網絡線程池的響應隊列中 * 由對應的網絡線程負責將 response 返回給 client * 請求隊列是所有網絡線程共享，響應隊列是專屬的 Purgatory 組件 * 職責：緩存延時請求（Delayed Request） * 延時請求：一時未能滿足條件不能立刻處理的請求 * e.g. acks=all 的 Produce 請求 需要等待 ISR 中所有的副本都接收了消息才能返回，此時處理該請求的 IO 線程必須等其他 Broker 寫入結果 請求分類 * 數據類請求：Produce、Fetch 這類請求 * 控制類請求：LeaderAndLsr、StopReplica