Kafka Broker端处理请求采用Reactor模型。每台Broker上有个类似于Dispatcher的Acceptor线程，还有若干个处理请求的Processor线程（当然真正处理请求逻辑的线程不是Processor，实际上是KafkaRequestHandler）。每个Processor线程启动后大致做以下这么几件事情：
1. 设置新的入站连接
2. 处理新的请求响应（所谓的处理也就是放入到响应队列中）
3. 执行Selector.select操作获取那些准备完毕的IO操作
4. 接收新的入站请求
5. 执行已发送响应的回调逻辑
6. 处理已断开连接
每个Broker启动之后它创建的Processor线程会不停地执行以上这些动作，循环往复，直至Broker被关闭。
我们重点看看第一步中的逻辑，以下是1.1.1版本的源码（选择1.1.1版本不是特意的，其实所有2.3版本之前都是差不多的情形）：
/**
* Register any new connections that have been queued up
*/
private def configureNewConnections() {
while (!newConnections.isEmpty) {
val channel = newConnections.poll()
try {
debug(s"Processor $id listening to new connection from ${channel.socket.getRemoteSocketAddress}")
selector.register(connectionId(channel.socket), channel)
} catch {
// We explicitly catch all exceptions and close the socket to avoid a socket leak.
case e: Throwable =>
val remoteAddress = channel.socket.getRemoteSocketAddress
// need to close the channel here to avoid a socket leak.
close(channel)
processException(s"Processor $id closed connection from $remoteAddress", e)
}
}
}
注意我标成红色的语句。基本上Processor线程设置新入站连接的方式就是一次性处理完才罢休。代码中的newConnections是java.util.concurrent.ArrayBlockingQueue实例。Acceptor线程也会访问newConnections，因此必须是线程安全的。
这种一次性处理完成才收手的做法在某些情况下是有风险的，比如当Kafka集群遭遇到DDOS攻击时，外部IP会创建海量的入站连接全部砸向newConnections中。此时Processor线程运行时会一直尝试消耗掉这些新连接，否则它不会干其他事情——比如处理请求等。换句话说，目前Kafka对新入站连接的处理优先级要高于已有连接。当遭遇连接风暴时，Kafka Broker端会优先处理新连接，因此可能造成已有连接上的请求处理被暂停，并最终导致超时。这样客户端得到请求超时通知后会会进一步地发送新的请求，因而出现雪崩效应。
另外Broker端维护每个连接也不是没有开销的。连接信息本身肯定要占用一些内容资源。如果是启用了SSL的连接，Kafka为额外为其维护一个48KB的临时缓冲区。因此一旦遭遇连接风暴，OOM错误是很常见的。
鉴于这些原因，社区在2.3版本改进了Broker端处理新连接请求的方式。首先阻塞队列保存新连接的个数不再是没有限制了，而是被固定为20，即每个Processor的新连接队列最大就是20个连接——这个写死在代码里面了，目前没法修改。第二、社区引入了新参数max.connections，用于控制Broker端所允许连接的最大连接数。你可以调节这个参数来控制一个Broker最多能接收多少个入站连接。这个参数可以在server.properties中被设置，也可以使用kafka-configs脚本动态修改。max.connections是全局性的，你也可以给每个监听器设置不同的连接数上限。比如你的监听器中同时使用了PLAINTEXT和SSL，那么你能够使用listener.name.plaintext.max.connections和listener.name.ssl.max.connections来为这两个listeners配置各自的连接数，命令如下：
$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config max.connections=100$ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config listener.name.plaintext.max.connections=80 Completed updating config for broker: 0. $ bin/kafka-configs.sh --bootstrap-server localhost:9092 --entity-type brokers --entity-name 0 --alter --add-config listener.name.ssl.max.connections=80 Completed updating config for broker: 0.
第三是Kafka Broker的每个Processor线程会在每轮任务结束之前尝试去关闭多余的连接。判断是否需要关闭多余连接的依据有两点：1. 总的连接数超过了max.connections值；2. 你为Broker设置了多个监听器，但Kafka会保护Broker内部连接使用的那个监听器。比如你如果设置了多个监听器：PLAINTEXT://9092, SSL://9093,SASL://9094，然后设置inter.broker.listener.name=SSL，那么SSL这套监听器下的连接是不会被Processor强行关闭的。
最后提一句，如果所有Processor的阻塞队列都满了， 那么前面的Acceptor线程会阻塞住，不会再接收任何入站请求。社区新增加了一个JMX指标来计算Acceptor线程被阻塞的时间比例：kafka.network:type=Acceptor,name=AcceptorBlockedPercent,listener={listenerName}