Reactor模式

在扯到Kafka之前我们先来说说Reactor模式，基本上只要是底层的高性能网络通信就离不开Reactor模式。像Netty、Redis都是使用Reactor模式。
像我们以前刚学网络编程的时候以下代码可是非常的熟悉，新来一个请求，要么在当前线程直接处理了，要么新起一个线程处理。

在早期这样的编程是没问题的，但是随着互联网的快速发展，单线程处理不过来，也不能充分的利用计算机资源。
而每个请求都新起一个线程去处理，资源的要求就太高了，并且创建线程也是一个重操作。
说到这有人想到了，那搞个线程池不就完事了嘛，还要啥Reactor。

池化技术确实能缓解资源的问题，但是池子是有限的，池子里的一个线程不还是得候着某个连接，等待指示嘛。现在的互联网时代早已突破C10K了。
因此引入的IO多路复用，由一个线程来监视一堆连接，同步等待一个或多个IO事件的到来，然后将事件分发给对应的Handler处理，这就叫Reactor模式。
网络通信模型的发展如下

Kafka所采用的Reactor模型如下

Kafka Broker 网络通信模型

简单来说就是，Broker 中有个Acceptor(mainReactor)监听新连接的到来，与新连接建连之后轮询选择一个Processor(subReactor)管理这个连接。
而Processor会监听其管理的连接，当事件到达之后，读取封装成Request，并将Request放入共享请求队列中。
然后IO线程池不断的从该队列中取出请求，执行真正的处理。处理完之后将响应发送到对应的Processor的响应队列中，然后由Processor将Response返还给客户端。
每个listener只有一个Acceptor线程，因为它只是作为新连接建连再分发，没有过多的逻辑，很轻量，一个足矣。
Processor 在Kafka中称之为网络线程，默认网络线程池有3个线程，对应的参数是num.network.threads。并且可以根据实际的业务动态增减。
还有个 IO 线程池，即KafkaRequestHandlerPool，执行真正的处理，对应的参数是num.io.threads，默认值是 8。IO线程处理完之后会将Response放入对应的Processor中，由Processor将响应返还给客户端。
可以看到网络线程和IO线程之间利用的经典的生产者 - 消费者模式，不论是用于处理Request的共享请求队列，还是IO处理完返回的Response。
这样的好处是什么？生产者和消费者之间解耦了，可以对生产者或者消费者做独立的变更和扩展。并且可以平衡两者的处理能力，例如消费不过来了，我多加些IO线程。
如果你看过其他中间件源码，你会发现生产者-消费者模式真的是太常见了，所以面试题经常会有手写一波生产者-消费者。