关于控制Broker端入站连接数的讨论

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}

 

posted @ 2019-07-29 11:36  huxihx  阅读(1149)  评论(0编辑  收藏  举报