29 | Kafka动态配置了解下？
2019-08-08 胡夕
Kafka核心技术与实战
进入课程
讲述：胡夕
时长 12:21 大小 11.33M
你好，我是胡夕。今天我要和你讨论的主题是：Kafka 的动态 Broker 参数配置。
什么是动态 Broker 参数配置？
在开始今天的分享之前，我们先来复习一下设置 Kafka 参数，特别是 Broker 端参数的方
法。
在 Kafka 安装目录的 config 路径下，有个 server.properties 文件。通常情况下，我们会
指定这个文件的路径来启动 Broker。如果要设置 Broker 端的任何参数，我们必须在这个
文件中显式地增加一行对应的配置，之后启动 Broker 进程，令参数生效。我们常见的做法
是，一次性设置好所有参数之后，再启动 Broker。当后面需要变更任何参数时，我们必须
下载APP
重启 Broker。但生产环境中的服务器，怎么能随意重启呢？所以，目前修改 Broker 端参
数是非常痛苦的过程。
基于这个痛点，社区于 1.1.0 版本中正式引入了动态 Broker 参数（Dynamic Broker
Configs）。所谓动态，就是指修改参数值后，无需重启 Broker 就能立即生效，而之前在
server.properties 中配置的参数则称为静态参数（Static Configs）。显然，动态调整参数
值而无需重启服务，是非常实用的功能。如果你想体验动态 Broker 参数的话，那就赶快升
级到 1.1 版本吧。
当然了，当前最新的 2.3 版本中的 Broker 端参数有 200 多个，社区并没有将每个参数都
升级成动态参数，它仅仅是把一部分参数变成了可动态调整。那么，我们应该如何分辨哪些
参数是动态参数呢？
如果你打开 1.1 版本之后（含 1.1）的 Kafka 官网，你会发现Broker Configs表中增加了
Dynamic Update Mode 列。该列有 3 类值，分别是 read-only、per-broker 和 cluster-
wide。我来解释一下它们的含义。
我来举个例子说明一下 per-broker 和 cluster-wide 的区别。Broker 端参数 listeners 想
必你应该不陌生吧。它是一个 per-broker 参数，这表示你只能为单个 Broker 动态调整
listeners，而不能直接调整一批 Broker 的 listeners。log.retention.ms 参数是 cluster-
wide 级别的，Kafka 允许为集群内所有 Broker 统一设置一个日志留存时间值。当然了，
你也可以为单个 Broker 修改此值。
使用场景
你可能会问，动态 Broker 参数的使用场景都有哪些呢？实际上，因为不必重启 Broker，
动态 Broker 参数的使用场景非常广泛，通常包括但不限于以下几种：
read-only。被标记为 read-only 的参数和原来的参数行为一样，只有重启 Broker，才
能令修改生效。
per-broker。被标记为 per-broker 的参数属于动态参数，修改它之后，只会在对应的
Broker 上生效。
cluster-wide。被标记为 cluster-wide 的参数也属于动态参数，修改它之后，会在整个
集群范围内生效，也就是说，对所有 Broker 都生效。你也可以为具体的 Broker 修改
cluster-wide 参数。
在这些使用场景中，动态调整线程池大小应该算是最实用的功能了。很多时候，当 Kafka
Broker 入站流量（inbound data）激增时，会造成 Broker 端请求积压（Backlog）。有
了动态参数，我们就能够动态增加网络线程数和 I/O 线程数，快速消耗一些积压。当突发
流量过去后，我们也能将线程数调整回来，减少对资源的浪费。整个过程都不需要重启
Broker。你甚至可以将这套调整线程数的动作，封装进定时任务中，以实现自动扩缩容。
如何保存？
由于动态配置的特殊性，它必然有和普通只读参数不同的保存机制。下面我来介绍一下
Kafka 是如何保存动态配置的。
首先，Kafka 将动态 Broker 参数保存在 ZooKeeper 中，具体的 znode 路径如下图所
示。
我来解释一下图中的内容。changes 是用来实时监测动态参数变更的，不会保存参数值；
topics 是用来保存 Kafka 主题级别参数的。虽然它们不属于动态 Broker 端参数，但其实
它们也是能够动态变更的。
动态调整 Broker 端各种线程池大小，实时应对突发流量。
动态调整 Broker 端连接信息或安全配置信息。
动态更新 SSL Keystore 有效期。
动态调整 Broker 端 Compact 操作性能。
实时变更 JMX 指标收集器 (JMX Metrics Reporter)。
users 和 clients 则是用于动态调整客户端配额（Quota）的 znode 节点。所谓配额，是指
Kafka 运维人员限制连入集群的客户端的吞吐量或者是限定它们使用的 CPU 资源。
分析到这里，我们就会发现，/config/brokers znode 才是真正保存动态 Broker 参数的地
方。该 znode 下有两大类子节点。第一类子节点就只有一个，它有个固定的名字叫 <
default >，保存的是前面说过的 cluster-wide 范围的动态参数；另一类则以 broker.id 为
名，保存的是特定 Broker 的 per-broker 范围参数。由于是 per-broker 范围，因此这类
子节点可能存在多个。
我们一起来看一张图片，它展示的是我的一个 Kafka 集群环境上的动态 Broker 端参数。
在这张图中，我首先查看了 /config/brokers 下的子节点，我们可以看到，这里面有 <
default > 节点和名为 0、1 的子节点。< default > 节点中保存了我设置的 cluster-wide
范围参数；0 和 1 节点中分别保存了我为 Broker 0 和 Broker 1 设置的 per-broker 参
数。
接下来，我分别展示了 cluster-wide 范围和 per-broker 范围的参数设置。拿
num.io.threads 参数为例，其 cluster-wide 值被动态调整为 12，而在 Broker 0 上被设置
成 16，在 Broker 1 上被设置成 8。我为 Broker 0 和 Broker 1 单独设置的值，会覆盖掉
cluster-wide 值，但在其他 Broker 上，该参数默认值还是按 12 计算。
