Kafka学习之旅(二): Kafka 常见配置参数解析

上一篇中主要介绍了Kafka 的一些相关的介绍和一些名词的解释。具体怎么搭建Kafka集群就不介绍了这个网上太多了。本篇主要介绍一下 搭建集群会用到的一些个人觉得比较重要的一些参数。下面先从broker开始吧
Kafka Broker 参数
目前Kafka broker 大致提供了200 个以上的参数，不过索性的是绝大部分不需要通常不需要去过问都有默认值，不然配个参数就是一个巨大的体力活了。
首先 Broker 是需要配置存储信息的，即 Broker 使用哪些磁盘。那么针对存储信息的重要参数有以下这么几个：

1. log.dirs：这是非常重要的参数并且没有默认值，指定了 Broker 需要使用的若干个文件目录路径。

2. log.dir：注意这是 dir，结尾没有 s,具体用处也不是很清楚据说它是补充上一个参数用的。
   基本上只要设置第一个就好了。而且更重要的是，在线上生产环境中一定要为log.dirs配置多个路径，具体格式是一个 CSV格式，也就是用逗号分隔的多个路径，比如/home/kafka1,/home/kafka2,/home/kafka3这样。如果有条件的话你最好保证这些目录挂载到不同的物理磁盘上。这样做有两个好处：
   提升读写性能：比起单块磁盘，多块物理磁盘同时读写数据有更高的吞吐量。
   能够实现故障转移：即 Failover

3. listeners：学名叫监听器，其实就是告诉外部连接者要通过什么协议访问指定主机名和端口开放的 Kafka 服务。

4. advertised.listeners：和 listeners 相比多了个advertised。Advertised 的含义表示宣称的、公布的，

Zookeeper 参数
相信小伙伴们对zookeeper 都不陌生这里就不多谈zookeeper了.这边主要设置的参数就是zookeeper.connect。这也是一个 CSV 格式的参数，比如我可以指定它的值为zk1:2181,zk2:2181,zk3:2181。2181 是 ZooKeeper的默认端口。
现在问题来了，如果我让多个 Kafka 集群使用同一套ZooKeeper 集群，那么这个参数应该怎么设置呢？这时候
chroot 就派上用场了。这个 chroot 是 ZooKeeper 的概念，类似于别名。如果你有两套 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，这样的格式是不对的。

Topic 参数

1. auto.create.topics.enable：是否允许自动创建Topic。
   建议在生产环境设置为false,虽然设置为true方便但是很难管理topic.

2. unclean.leader.election.enable：是否允许Unclean Leader 选举。
   什么是unclean呢,我们知道kafka是多副本的,并且只有一个是leader副本向外提供服务,如果leader副本挂掉了会从副本集合中选出一个副本成为leader副本继续提供服务，那么这个时候就来了是不是所有的副本都有资格竞争leader呢显然不是的,如果副本落后leader太多会丢失一部分数据显然是不合适的。如果设置为false 那么就不让它参加选举，如果是true 就让他参加选举。主要是kafka有些版本的默认参数是true有些是fasle这个很坑所以干脆提出来设置为false好了。

3. auto.leader.rebalance.enable：是否允许定期进行 Leader 选举。
   设置它的值为 true 表示允许 Kafka 定期地对一些 Topic 分区进行Leader重选举。Leader 选举的最大不同在于，它不是选 Leader，而是换Leader！比如 Leader A 一直表现得很好，突然把它撤了让副本B去当leader这样付出的代价是很大的。

数据留存
Kafka会实例化保存我们生产的数据到磁盘,可以方便用户做一些其他的操作但是同时也带了一个问题数据的保留时间，如果太长会造成资源浪费甚至是磁盘空间不足而导致服务宕机。留存时间太少的话万一下游出现了数据问题需要重新消费的话，可是队列也清除掉了。所以设置一个合理的时间尤其重要。

1. log.retention.{hour|minutes|ms}：这是个“三兄弟”，都是控制一条消息数据被保存多长时间。从优先级上来说 ms设置最高、minutes 次之、hour 最低。
2. log.retention.bytes：这是指定 Broker 为消息保存的总磁盘容量大小。
3. message.max.bytes：控制 Broker 能够接收的最大消息大小

Topic 级别参数
Kafka 支持为每一个Topic 设置参数这个也是Kafka 一个比较骚的特性了。为什么要提供一个这样的功能。
例如上文我提到了消息数据的留存时间参数，在实际生产环境中，如果为所有 Topic 的数据都保存相当长的时间，这样做既不高效也无必要。更适当的做法是允许不同部门的 Topic 根据自身业务需要，设置自己的留存时间。
那么问题来了，如果同时设置了 Topic 级别参数和全局 Broker 参数，到底听谁的呢？哪个说了算呢？答案就是 Topic 级别参数会覆盖全局参数。
当前最新的 2.2 版本总共提供了大约 25 个 Topic 级别的参数，下面挑两个介绍一下。

1. retention.ms：规定了该 Topic 消息被保存的时长。默认是 7 天，即该 Topic 只保存最近 7 天的消息。一旦设置了这个值，它会覆盖掉 Broker 端的全局参数值。
2. retention.bytes：规定了要为该 Topic 预留多大的磁盘空间。和全局参数作用相似，这个值通常在多租户的Kafka 集群中会有用武之地。当前默认值是 -1，表示可以无限使用磁盘空间。
   那么Topic 级别参数怎么创建和修改呢肯定不是卸载配置文件的不然每次修改还得重启集群太傻了。

主要通过下面两种方式:

1. 可以在Topic创建时添加
   ./kafka-topics.sh --bootstrap-server=localhost:9092 --create --topic=test --partitions=1 --replication-factor=1 --config retention.ms=15552000000 --config max.message.bytes=5242880

2. 可以通过脚本修改
   ./kafka-configs.sh --zookeeper=localhost:2181 --entity-type topics --entity-name test --alter --add-config 'max.message.bytes=5242880,retention.ms=15552000000' --delete-config retention.bytes

JVM 参数
Kafka 是由scala 语言编写的运行在java虚拟机之上那么对于JVM的参数调优就必不可少了,建议使用1.8及其以上版本因为现在kafka最新版已经放弃了对1.7的支持。
1.堆大小 Kafka 默认的堆大小为1GB 自己测试确实是够用了但是对于生产来说貌似有点小了。可以根据你所使用的机器来决定例如设置6GB.
2.垃圾回收器
Java9 默认使用G1 回收器如果你是java8 的话还是需要手动指定的–XX:+UseG1GC

那么怎么设置呢其实Kafka 提供了两个参数
KAFKA_HEAP_OPTS：指定堆大小。
KAFKA_JVM_PERFORMANCE_OPTS：指定 GC 参数。
所以只需要这样就好了

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

操作系统参数
最后我们来讲讲操作系统参数
主要有

1. 文件描述符限制
   首先是ulimit -n。我觉得任何一个 Java 项目最好都调整下这个值。不然可能你会遇到Too many open files”的错误。

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

3. 提交时间
   提交时间或者说是 Flush 落盘时间。向 Kafka 发送数据并不是真要等数据被写入磁盘才会认为成功，而是只要数据被写入到操作系统的页缓存（Page Cache）上就可以了，随后操作系统根据 LRU 算法会定期将页缓存上的数据落盘到物理磁盘上。这个定期就是由提交时间来确定的，默认是 5 秒。一般情况下我们会认为这个时间太频繁了，可以适当地增加提交间隔来降低物理磁盘的写操作。当然你可能会有这样的疑问：如果在页缓存中的数据在写入到磁盘前机器宕机了，那岂不是数据就丢失了。的确，这种情况数据确实就丢失了，但鉴于 Kafka 在软件层面已经提供了多副本的冗余机制，因此这里稍微拉大提交间隔去换取性能还是一个合理的做法