本文共 4886 字，大约阅读时间需要 16 分钟。

kafka集群参数配置包括 Broker端参数、Topic级别的参数、JVM端参数 以及 操作系统级别的参数配置；

该篇用于介绍常用且不能使用默认值的一些参数配置，因为有些配置的重要性并未在官方文档中表现出来；从实际表现看，很多参数对系统的影响要比从文档上看更加重要。

1.Broker 端参数

a.针对储存信息的参数

• log.dirs: 指定了 Broker 需要使用的若干个文件目录路径; 该参数没有默认值，必修由用户亲自指定；
• log.dir: 指定了Broker需要使用的单个文件目录路径；用于补充log.dirs参数用的；

以上两个参数，通常只需要配置 `log.dirs`即可；配置多个路径时使用逗号“,”分割；如果有条件的话你最好保证这些目录挂载到不同的物理磁盘上，主要好处有：	1. 提升读写性能：比起单块磁盘，多块物理磁盘同时读写数据有更高的吞吐量。	2. 能够实现故障转移：即 Failover。这是 Kafka 1.1 版本新引入的强大功能。	   之前，只要 Kafka Broker 使用的任何一块磁盘挂掉，整个 Broker 进程都会关闭。	   但是自 1.1 开始，这种情况被修正：坏掉的磁盘上的数据会自动地转移到其他正常的磁盘上，而且 Broker 还能正常工作。	   这个改进正是我们舍弃 RAID 方案的基础：没有这种 Failover 的话，我们只能依靠 RAID 来提供保障。

b.kafka 与 zooKeeper相关的参数

ZooKeeper是一个分布式协调框架，负责协调管理并保存 Kafka 集群的所有元数据信息，比如集群都有哪些 Broker 在运行、创建了哪些 Topic，每个 Topic 都有多少分区以及这些分区的 Leader 副本都在哪些机器上等信息。

• zookeeper.connect: Kafka使用的ZooKeeper集群地址集合；可指定多个，之间用逗号分割。eg: zk1:2181,zk2:2181,zk3:2181

如果你有两套 Kafka 集群，假设分别叫它们 kafka1 和 kafka2，那么两套集群的 `zookeeper.connect`参数可以这样指定：	zk1:2181,zk2:2181,zk3:2181/kafka1	zk1:2181,zk2:2181,zk3:2181/kafka2切记 chroot 只需要写一次，而且是加到最后的。错误指定方式：	zk1:2181/kafka1,zk2:2181/kafka2,zk3:2181/kafka3

c.针对Broker连接的参数

客户端程序或其他 Broker 如何与该 Broker 进行通信的设置。有以下三个参数：

• listeners: 监听器，用于告诉外部连接者要通过什么协议访问指定主机名和端口开放的 Kafka 服务。
• advertised.listeners：和 listeners 相比多了个 advertised。Advertised 的含义表示宣称的、公布的，就是说这组监听器是 Broker 用于对外发布的。
• host.name/port：这两个参数是过期参数，不需要指定值。

监听器的概念: 从构成上来说，它是若干个逗号分隔的三元组，每个三元组的格式为:	
   <协议名称，主机名，端口号>
    这里的协议名称可能是标准的名字，比如 PLAINTEXT 表示明文传输、SSL 表示使用 SSL 或 TLS 加密传输等；也可能是你自己定义的协议名字，比如:	CONTROLLER: //localhost:9092一旦你自己定义了协议名称，你必须还要指定 `listener.security.protocol.map` 参数告诉这个协议底层使用了哪种安全协议，比如指定:	listener.security.protocol.map=CONTROLLER:PLAINTEXT表示这个自定义协议底层使用明文不加密传输数据。三元组种的主机名 --> 在IP地址和主机名之间，建议使用主机名，即 Broker 端和 Client 端应用配置中全部填写主机名。 Broker 源代码中也使用的是主机名，如果你在某些地方使用了 IP 地址进行连接，可能会发生无法连接的问题。
   

d.针对Topic管理的参数

• auto.create.topics.enable：是否允许自动创建 Topic。

该参数建议最好设置成 false，即不允许自动创建 Topic。在线上环境里面有很多名字稀奇古怪的 Topic，大概都是因为该参数被设置成了 true 的缘故。Topic 应该由运维严格把控，决不能允许自行创建任何 Topic。

• unclean.leader.election.enable：是否允许 Unclean Leader 选举。

kafka中自由Leader副本对外提供服务；该参数的运用场景主要是：	那些保存数据比较多的副本均挂死的情况下，是否还要在落后进度较多的副本中竞选出Leader	false: 落后太多的副本不允许竞争Leader; 以上场景会使得当前分区不可用；	true：允许竞争，这样会导致部分数据丢失；该参数在最新版本中默认为false, 通常不需要修改；但在之前版本中默认值经过了多次修改；所以最好显示设置为true或者false；

• auto.leader.rebalance.enable：是否允许定期进行 Leader 选举。

true：表示允许 Kafka 定期地对一些 Topic 分区进行 Leader 重选举;它需要满足一定的条件才会发生。严格来说它与上一个参数中 Leader 选举的最大不同在于，它不是选 Leader，而是换 Leader！比如 Leader A 一直表现得很好，但若 `auto.leader.rebalance.enable=true`，那么有可能一段时间后 Leader A 就要被强行卸任换成 Leader B。

e.针对数据留存的参数

• log.retention.{hour|minutes|ms}：三个参数用来控制一条消息数据被保存多长时间。从优先级上来说 ms 设置最高、minutes 次之、hour 最低。

虽然 ms 设置有最高的优先级，但是通常情况下我们还是设置 hour 级别的多一些

• log.retention.bytes ：这是指定 Broker 为消息保存的总磁盘容量大小。

默认值为-1, 表示不限容量这个参数真正发挥作用的场景其实是在云上构建多租户的 Kafka 集群：	设想你要做一个云上的 Kafka 服务，每个租户只能使用 100GB 的磁盘空间，	为了避免有个“恶意”租户使用过多的磁盘空间，设置这个参数就显得至关重要；

• message.max.bytes：控制 Broker 能够接收的最大消息大小。

默认值为 1000012，不到 1MB。实际场景中突破 1MB 的消息是常见的；因此在线上环境中设置一个比较大的值还是比较保险的做法。毕竟它只是一个标尺而已，仅仅衡量 Broker 能够处理的最大消息大小，即使设置大一点也不会耗费什么磁盘空间的。

2.Topic级别的参数

Topic级别参数优先级高于全局Broker参数； 每个Topic都能设置自己的参数值；

a.针对消息存储的参数

• retention.ms：该Topic消息被保存的时长； 默认值为7天； 一旦设置，会覆盖Broker端的全局参数值。
• retention.bytes：该Topic预留的磁盘空间大小；默认值为-1（不设限）；运用于多租户场景。
• max.message.bytes： 决定Kefka Broker能够正常接收该Topic的最大消息大小；

设置Topic级别参数的方法：	1. 创建 Topic 时进行设置		bin/kafka-topics.sh --bootstrap-server localhost:9092 --create --topic transaction --partitions 1 --replication-factor 1 --config retention.ms=15552000000 --config max.message.bytes=5242880	2. 修改 Topic 时设置（推荐）		bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name transaction --alter --add-config max.message.bytes=10485760

3.JVM参数

Kafka不建议运行在 Java6 或 7的环境上；Java6 太旧；Kafka在2.0.0版本开始摒弃了对 Java7 的支持。

Kafka设置JVM参数的方法，设置环境变量：

• KAFKA_HEAP_OPTS：指定堆大小。
• KAFKA_JVM_PERFORMANCE_OPTS：指定 GC 参数。

$> export KAFKA_HEAP_OPTS=--Xms6g  --Xmx6g$> export KAFKA_JVM_PERFORMANCE_OPTS= -server -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:InitiatingHeapOccupancyPercent=35 -XX:+ExplicitGCInvokesConcurrent -Djava.awt.headless=true$> bin/kafka-server-start.sh config/server.properties

a.堆大小设置

据称，将JVM堆大小设置为 6GB。 这是一个业界比较公认的合理值；原因：Kafka Broker在与客户端进行交互式会在JVM堆上创建大量的 ByteBuffer 实例，Heap Size不能太小；

b.垃圾回收（GC）设置

如果使用的 Java7，需要根据如下条件进行配置：

1. 如果 Broker 所在机器的 CPU 资源非常充裕，建议使用 CMS 收集器。启动方法，指定：	-XX:+UseCurrentMarkSweepGC2. 否则使用吞吐量收集器。开启方法是指定：	-XX:+UseParallelGC

如果使用的 Java8， 可以指定为G1收集器； G1收集器在没有任何调优的情况下，比CMS更出色，主要体现在更少的 Full GC，需要调整的参数更少等；

4.操作系统参数

Kafka需要关注的OS参数：

• 文件描述符限制: ulimit -n

文件描述符系统资源并没有想象的昂贵，通常将它设置成一个超大的值时合理的做法：	ulimit -n 1000000如果不设置的话，可能会看到 “Too many open files” 错误；

• 文件系统类型：指如 ext3、ext4或XFS这样的日志型文件系统； 性能：ZFS(尝鲜) > XFS > ext4
• Swappiness：swap调优， swap建议设置为一个较小的值；这样能在Broker性能急剧下降时，有时间进一步调优和诊断；建议设置为1；

小知识：当swap=0时，如果物理内存耗尽，那么操作系统会触发 OMM killer组件，随机挑选一个进程kill掉，而用户在此期间无法感知；

• 提交时间：Flush落盘时间；Kafka数据被写入到操作系统的页缓存（Page Cache）上就被认为写入成功，随后操作系统根据 LRU 算法会定期（默认5秒）将页缓存上的“脏”数据落盘到物理磁盘上；可以适当增加提交时间间隔；由于Kafka在软件层面已经提供了多副本的冗余机制，不用担心出现数据丢失的情况；