Kafka之常用参数配置整理

Kafka之常用参数配置整理

一、Broker端参数

1、存储

• log.dirs：指定broker使用的若干个文件目录路径。（无默认值，必须指定）
• log.dir：配置单个路径，用于上个参数的补充。

通常情况下，我们只需要设置

log.dirs

即可。而且建议配置多个路径，比如：

/home/kafka1,/home/kafka2,/home/kafka3

。并且，如果条件允许，最好将这些目录挂载到不同的物理磁盘。这样做有两个好处：

• 提升读写性能。多块物理磁盘同时读写数据具有更高的吞吐量
• 故障转移（Failvoer）。在之前Kafka Broker任何一块磁盘挂掉，整个Broker都会停止提供服务。在Kafka1.1开始，坏掉的磁盘上的数据会自动转移到其他正常磁盘上，并且Broker还能正常工作。

2、Zookeeper

Zookeeper在Kafka中扮演着重要的角色，它是一个分布式协调框架，负责协调管理Kafka集群的所有元数据。比如：Broker信息、Topic、每个Topic的partition、partition的Leader副本信息等。

• zookeeper.connect：链接zookeeper的地址。比如我可以指定它的值为zk1:2181,zk2:2181,zk3:2181

如果需要让多个Kafka集群使用同一个Zookeeper集群，这个参数应该怎么设置？

chroot

是Zookeeper的概念，类似于别名。

如果你有两套 Kafka 集群，假设分别叫它们

kafka1

和

kafka2

，那么两套集群的

zookeeper.connect

参数可以这样指定：

zk1:2181,zk2:2181,zk3:2181/kafka1

和

zk1:2181,zk2:2181,zk3:2181/kafka2

。切记 chroot 只需要写一次，而且是加到最后的。

3、连接

客户端或其他Broker和本Broker的通信设置。

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

监听器的格式：

<协议名称，主机名，端口号>

。比如

protocol://host:port

4、Topic管理

• auto.create.topics.enable：是否允许自动创建topic
• unclean.leader.election.enable：是否允许Unclean Leader选举
• auto.leader.rebalance.enable：是否允许定期选举

auto.create.topics.enable

在线上生产环境一定要改为false，特别是将Kafka用作基础组件，会出现各种稀奇古怪的topic。运维需要严格把控Topic的创建。

unclean.leader.election.enable

Unclean Leader选举，建议设置为false。解释一下unclean，就是那些同步数据落后太多的

partition

。最新版Kafka默认是false，即不允许落后太多的副本进行Leader选举。如果设置为true，那么那些同步较为落后的副本也会参与选举，如果选为Leader，其他副本就会截取掉多余的数据，造成数据丢失。

但是。假设那些保存数据较多的副本都挂了，并且参数设置为false，服务将会不可用。如果设置为true，这时参数就派上用场了，可以从同步较慢的主机中选择leader，虽然丢失数据，Broker还是可以提供服务。

auto.leader.rebalance.enable

如果设置为true，表示允许Kafka定期对一些Topic的partition进行Leader重选举。上个参数发生在Leader故障的情况，这个参数和它不同的是，他不是选Leader，而是定期换Leader。比如尽管LeaderA表现一直很有好，但是参数设置为true的情况下，有可能会强行换副本B为Leader。

换一次Leader的代价很高，并且这种操作实质上没有任何性能收益，故建议设置为false

5、数据留存

• log.retention.{hours|minutes|ms}：控制一条消息数据被保存多长时间。从优先级上来说 ms 最高、minutes 次之、hours 最低。
• log.retention.bytes：指定 Broker 为消息保存的总磁盘容量大小。
• message.max.bytes：控制 Broker 能够接收的最大消息大小。

log.retention.hours=168

默认设置，表示保存7天，自动删除七天前的数据，通常情况下，在保证磁盘空间足够时，我们尽量将这个值调大。

log.retention.bytes=-1

默认设置，代表不限制Broker容量。

message.max.bytes=1000012

默认还不到1MB，这个值需要进行调整，线上环境超过1MB的消息场景还是比较多的，设置一个比较大的值比较保险。

二、Topic级别参数

如果同时设置了Topic级别参数和全局Broker参数，

以Topic级别参数为准，覆盖全局Broker参数

。

• retention.ms：设置该Topic消息被保存的时间，默认是7天。一旦设置将会覆盖Broker的全局参数
• retention.bytes：设置为该Topic预留多大的磁盘空间，默认为-1，不做限制。
• max.message.bytes：如果公司的Kafka作为基础组件，上面跑的业务数据是比较多的，全局参数较难均衡，可以为每个Topic定制消息大小。

比如使用自带的命令

kafka-configs

来修改 Topic 级别参数，将发送最大值设置为10MB。

bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name transaction --alter --add-config max.message.bytes=10485760

三、JVM参数

Kafka旧版本是用Scala语言编写的，新版本用Java语言，无论是哪个，终归会编译为

class

文件运行在JVM上，因此JVM参数对于Kafka集群相当重要。

JDK版本选择：JDK6已经太过陈旧了，并且在kafka2.0.0版本开始已经放弃了对JDK7的支持，所以建议至少使用JDK8。

堆：Kafka默认堆大小为1GB，这显然是不够的，Broker在和客户端交互时，会产生大量的ByteBuffer对象。业内公认较为合理的值为6GB。

GC：如果在使用JDK8，那么可以手动设置为G1收集器，在没有任何调优的情况下，G1的表现要比CMS出色，主要体现在更少的Full GC，需要调整的参数更少。

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

比如，在启动Broker前，可以这样进行设置：

$> 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

四、操作系统参数

• 文件描述符限制。通常情况下将它设置成一个超大的值是合理的做法，比如ulimit -n 1000000。其实设置这个参数一点都不重要，但不设置的话后果很严重，比如你会经常看到“Too many open files”的错误。
• 文件系统类型：文件系统指的是如 ext3、ext4 或 XFS 这样的日志型文件系统。根据官网的测试报告，XFS 的性能要强于 ext4，所以生产环境最好还是使用 XFS。
• Swappiness：很多文章建议设置为0，将swap禁用避免Kafka进程使用swap空间。但是当物理内存耗尽时，操作系统会触发OOM killer，随机挑选一个进程然后kill掉，根本不给用户任何预警。 但如果设置成一个比较小的值，当开始使用 swap 空间时，你至少能够观测到 Broker 性能开始出现急剧下降，从而给你进一步调优和诊断问题的时间。比如 1
• 提交时间：即Flush落盘时间。向 Kafka 发送数据并不是真要等数据被写入磁盘才会认为成功，而是只要数据被写入到操作系统的页缓存（Page Cache）上就可以了，随后操作系统根据 LRU 算法会定期将页缓存上的“脏”数据落盘到物理磁盘上。这个定期就是由提交时间来确定的，默认是 5 秒。一般情况下我们会认为这个时间太频繁了，可以适当地增加提交间隔来降低物理磁盘的写操作。当然你可能会有这样的疑问：如果在页缓存中的数据在写入到磁盘前机器宕机了，那岂不是数据就丢失了。的确，这种情况数据确实就丢失了，但鉴于 Kafka 在软件层面已经提供了多副本的冗余机制，因此这里稍微拉大提交间隔去换取性能还是一个合理的做法。