本文为博主自学笔记整理，内容来源于互联网，如有侵权，请联系删除。
个人笔记：https://www.dbses.cn/technotes
关于如何处理请求，我们很容易想到的方案有两个。
- 顺序处理请求
伪代码大概是这个样子：
while (true) {
Request request = accept(connection);
handle(request);
}
这种方式的吞吐量太差，每个请求都必须等待前一个请求处理完毕才能得到处理。适用于请求发送非常不频繁的系统。
- 异步处理请求
伪代码大概是这个样子：
while (true) {
Request = request = accept(connection);
Thread thread = new Thread(() -> handle(request););
thread.start();
}
这个方法的好处是，它是完全异步的，每个请求的处理都不会阻塞下一个请求。
缺陷是开销极大，在某些场景下甚至会压垮整个服务。这个方法也只适用于请求发送频率很低的业务场景。
Kafka 处理请求的方式
Kafka 使用的是 Reactor 模式。
简单来说，Reactor 模式是事件驱动架构的一种实现方式，特别适合应用于处理多个客户端并发向服务器端发送请求的场景。Reactor 模式的架构图如下：
根据上图，Reactor 模式主要特点是分发。
Reactor 有个请求分发线程 Dispatcher，也就是图中的 Acceptor，它会将不同的请求下发到多个工作线程中处理。
Acceptor 线程只是用于请求分发，不涉及具体的逻辑处理，非常轻量级，因此有很高的吞吐量表现。而这些工作线程可以根据实际业务处理需要任意增减，从而动态调节系统负载能力。
Kafka 的处理请求模型类似：
SocketServer 组件：它也有对应的 Acceptor 线程和一个网络线程池。
Acceptor 线程：采用轮询的方式将入站请求公平地发到所有网络线程中。
网络线程池：处理 Acceptor 线程分发的工作任务。
Kafka 提供了 Broker 端参数 num.network.threads，用于调整该网络线程池的线程数。其默认值是 3，表示每台 Broker 启动时会创建 3 个网络线程，专门处理客户端发送的请求。
Kafka 网络线程处理请求的具体过程
客户端发来的请求会被 Broker 端的 Acceptor 线程分发到任意一个网络线程中，Kafka 在这个环节又做了一层异步线程池的处理，我们一起来看一看下面这张图。
主要步骤如下：
-
当网络线程拿到请求后，会将请求放入到一个共享请求队列中。
-
Broker 端有个 IO 线程池，负责从该队列中取出请求，执行真正的处理。
Broker 端参数 num.io.threads 控制了这个线程池中的线程数。 目前该参数默认值是 8，表示每台 Broker 启动后自动创建 8 个 IO 线程处理请求。
-
处理请求。如果是 PRODUCE 生产请求，则将消息写入到底层的磁盘日志中；如果是 FETCH 请求，则从磁盘或页缓存中读取消息。
-
IO 线程处理完请求后，会将生成的响应发送到网络线程池的响应队列中，然后由对应的网络线程负责将 Response 返还给客户端。
为什么网络线程不直接处理？即为什么要有 2、3 步骤？
请求队列与响应队列的差别
请求队列是所有网络线程共享的，而响应队列则是每个网络线程专属的。
这么设计的原因就在于，Dispatcher 只是用于请求分发而不负责响应回传，因此只能让每个网络线程自己发送 Response 给客户端，所以这些 Response 也就没必要放在一个公共的地方。
Purgatory 组件
图中还有一个叫 Purgatory 的组件，这是 Kafka 中著名的“炼狱”组件。它是用来缓存延时请求（Delayed Request）的。
所谓延时请求，就是那些一时未满足条件不能立刻处理的请求。比如设置了 acks=all 的 PRODUCE 请求，一旦设置了 acks=all，那么该请求就必须等待 ISR 中所有副本都接收了消息后才能返回，此时处理该请求的 IO 线程就必须等待其他 Broker 的写入结果。当请求不能立刻处理时，它就会暂存在 Purgatory 中。稍后一旦满足了完成条件，IO 线程会继续处理该请求，并将 Response 放入对应网络线程的响应队列中。