kafka、关键配置参数

Broker参数

• log.dirs：文件目录路径，可以填写多个，使用逗号隔开。

建议使用多个目录，并且挂载到不同的物理磁盘上。提升读写性能：比起单块磁盘，多块物理磁盘同时读写数据有更高的吞吐量。Kafka 1.1 版本后，单块磁盘坏掉，数据会自动地转移到其他正常的磁盘上，提高 Broker 可用性。

• zookeeper.connect

如果你有两套 Kafka 集群，想共用一个zk的集群，假设分别叫它们 kafka1 和 kafka2，zookeeper.connect参数可以这样指定：zk1:2181,zk2:2181,zk3:2181/kafka1和zk1:2181,zk2:2181,zk3:2181/kafka2

• listeners：告诉外部连接者要通过什么协议访问指定主机名和端口开放的 Kafka 服务。

• advertised.listeners：这组监听器是 Broker 用于对外发布的。 advertised.listeners主要是为外网访问用的。如果clients在内网环境访问Kafka不需要配置这个参数。

• auto.create.topics.enable ：建议设置成 false，避免错误创建topic，导致服务器上有很多topic，但又不敢删除。

• unclean.leader.election.enable：是关闭 Unclean Leader 选举的，设置成 false，不能让那些落后太多的副本竞选 Leader。

• auto.leader.rebalance.enable：true 表示允许 Kafka 定期地对一些 Topic 分区进行 Leader 重选举，分区重新选举是为了broker负载更加均衡，但client重连leader成本也很高，建议设在为false。

• log.retention.{hours|minutes|ms}：控制一条消息数据被保存多长时间。ms 设置最高、minutes 次之、hours 最低。

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

• message.max.bytes：控制 Broker 能够接收的最大消息大小。默认的 1000012 ，建议重新设置。

• auto.offset.reset  什么时候需要使用auto.offset.rese的设置？情况1： 如果 Kafka broker端没有保存这个位移值，那么consumer会看auto.offset.reset的值。情况2：consumer拿到位移值开始消费，如果后面发现它要读取消息的位移在Kafka中不存在（可能对应的消息已经被删除了），那么它也会看auto.offset.reset的值。

 

Topic 级别参数

 Topic 级别参数会覆盖全局 Broker 参数的值，而每个 Topic 都能设置自己的参数值，这就是所谓的 Topic 级别参数。

• retention.ms：规定了该 Topic 消息被保存的时长。默认是 7 天，即该 Topic 只保存最近 7 天的消息。一旦设置了这个值，它会覆盖掉 Broker 端的全局参数值。

• max.message.bytes 它决定了 Kafka Broker 能够正常接收该 Topic 的最大消息大小。配套要修改一下Broker的replica.fetch.max.bytes 保证复制正常，消费者要修改配置 fetch.message.max.bytes。

可用使用kafka-configs.sh来修改 Topic 级别参数。例如发送最大值是 10MB 的消息

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

 

 

JVM参数

• 至少使用 Java 8

• JVM 堆大小设置成 6GB ，这是目前业界比较公认的一个合理值。

如果你依然在使用 Java 7，那么可以根据以下法则选择合适的垃圾回收器：如果 Broker 所在机器的 CPU 资源非常充裕，建议使用 CMS 收集器。启用方法是指定-XX:+UseCurrentMarkSweepGC。否则，使用吞吐量收集器。开启方法是指定-XX:+UseParallelGC。

使用 Java 8 ，jdk8还是需要显式指定的G1。在没有任何调优的情况下，G1 表现得要比 CMS 出色，主要体现在更少的 Full 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

 

操作系统参数

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

• 文件系统类型， 官网的测试报告，XFS 的性能要强于 ext4，所以生产环境最好还是使用 XFS。对了，最近有个 Kafka 使用 ZFS 的数据报告，貌似性能更加强劲。

• Swappiness

swap 的调优。网上很多文章都提到设置其为 0，将 swap 完全禁掉以防止 Kafka 进程使用 swap 空间。我个人反倒觉得还是不要设置成 0 比较好，我们可以设置成一个较小的值。为什么呢？因为一旦设置成 0，当物理内存耗尽时，操作系统会触发 OOM killer 这个组件，它会随机挑选一个进程然后 kill 掉，即根本不给用户任何的预警。但如果设置成一个比较小的值，当开始使用 swap 空间时，你至少能够观测到 Broker 性能开始出现急剧下降，从而给你进一步调优和诊断问题的时间。基于这个考虑，建议将 swappniess 配置成一个接近 0 但不为 0 的值，比如 1。

• 提交时间（Flush 落盘时间）

向 Kafka 发送数据并不是真要等数据被写入磁盘才会认为成功，而是只要数据被写入到操作系统的页缓存（Page Cache）上就可以了，随后操作系统根据 LRU 算法会定期将页缓存上的“脏”数据落盘到物理磁盘上。这个定期就是由提交时间来确定的，默认是 5 秒。一般情况下我们会认为这个时间太频繁了，可以适当地增加提交间隔来降低物理磁盘的写操作。