kafka-其他参数详解

kafka-其他参数详解

主要介绍下kafka的producer配置参数，只取了其中的一部分常用的，后续的有时间，也会补充一些，更多的详细参数，可以参考《kafka官网》，参数的内容，主要是选取《apache kafka实战》书中的一些讲解和官网相互参看

topic 级别参数

topic级别的参数是指覆盖 broker 端全局参数；每个不同的 topic 都可以设置自己的参数值。

举例来说，上面提到的日志留存时间，显然，在实际使用中，在全局设置一个通用的留存时间并不方便，因为每个业务的 topic 可能有不同的留存策略。如果只能设置全局参数，那么势必要取所有业务留存时间的最大值作为全局参数值，这样必然会造成空间的浪费。因此 Kafka 提供了很多topic 级别的参数；常见的包括如下几个：

delete.retention.ms：每个 topic 可以设置自己的日志留存时间以覆盖全局默认值；

max.message.bytes：覆盖全局的message.max.bytes ，即为每个 topic 指定不同的最大消息存储KB；

retention. bytes：覆盖全局的 log.retention. bytes ，每个 topic 设置不同的日志留存尺寸；

GC参数

Kafka broker 端代码虽然是用 Scala 语言编写的，但终归要编译为.class 文件在 JVM 上运行；既然是 JVM 上面的应用，垃圾回收（ garbage collection, GC ）参数的设置就显得非常重要；

Java7 ，那么在选择 GC 收集器时可以根据以下法则进行确认：

1、 CPU 资源非常充裕，推荐使用 CMS 收集器;启用方法为－:XX:+UseCurrentMarkSweepGC

2、相反地，则使用吞吐量收集器，这样不会挤占紧张的CPU 资源， 启用方法为－XX:+UseParallelGC

Java8，这是推荐的版本 实际上如果用户在 Kafka 官网上下载使用Scala 2.12 编译的 Kafka 进制压缩包，那么就必须安装井使用 Java推荐使用 GI 垃圾收集器；在没有任何调优的情况下， GI 收集器本身会比 CMS 表现出更好的性能；主要体现在 Full GC 的次数更少、需要做调的参数更少等方面 因此推荐用户始终使用 GI 收集器，不论是在 broker 端还是在 clients 端。

JVM 参数

Kafka 推荐用户使用最新版本的 JDK一一当前最新的 Oracle JDK 版本 1.8；

另外鉴于 Kafka broker 主要使用的是堆外内存，即大量使用操作系统的页缓存，因此其实并不需要为JVM 分配太多的内存。

在实际使用中，通常为 broker 设置不超过 6GB 的堆空间；以下就是一份典型的生产环境中的 口币 参数列表：

-Xmx6g 
-Xms6g 
-XX:MetaspaceSize=96m 
-XX:+UseGlGC
-XX:MaxGCPauseMillis=20 
-XX:InitiatingHeapOccupancyPercent=35 
-XX:G1HeapRegionSize=l6M 
-XX:MinMetaspaceFreeRatio=5O 
-XX:MaxMetaspaceFreeRatio=80 

OS 参数

文件描述符限制

Kafka 会频繁地创建井修改文件系统中的文件，这包括消息的日志文件、索引文件及各种元数据管理文件等。因此如果一个 broker上面有很多 topic 的分区，那么这个 broker 势必就需要打开很多个文件；

大致数量约等于分区数 *（分区总大小／日志段大小)*3 。

举一个例子，假设 broker 上保存了 50 个分区，每个分区平均尺寸是 10GB ，每个日志段大小是 1GB ，那么这个 broker 需要维护 1500 个左右的文件描述符。因此在实际使用场景中最好首先增大进程能够打开的最大文件描述符上限；

比如设置 个很大的值，如 100000 。具体设置方法为

ulimit -n 100000

Socket 缓冲区大小

这里指的是 OS 级别的 Socket 缓冲区大小，而非 Kafka 自己提供Socket 缓冲区参数； 事实上， Kafka 自己的参数将其设置为 64KB，这对于普通的内网环境而言通常是足够的；因为内网环境下往返时间（ round-trip time, RTT） 一般都很低，不会产生过多的数据堆积在 Socket 缓冲区中；但对于那些跨地区的数据传输而言，仅仅增 Kafka 参数就不够了，因为前者也受限于 OS 级别的设置；因此如果是做远距离的数据传输，那么建议将 OS 级别的 Socket 缓冲区调大；比如增加到 128KB，甚至更大。

最好使用 Ext4 或×FS 文件系统

其实 Kafka 操作的都是普通文件，并没有依赖于特定的文件系统，但依然推荐使用 Ext4 或XFS 文件系统；特别是 XFS 通常都有更好的性能。这种性能的提升主要影响的是kafka 的写入性能。根据官网的测试报告，使用XFS 的写入时间大约是 16 毫秒，而使用 Ext 大约是 50 毫秒。

因此生产环境中最好使用 XFS 文件系统。

关闭 swap

其实这是很多使用磁盘的应用程序的常规调优手段，具体命令为 sysctl vm.swappiness = ＜一个较小的数>，即大幅度降低对 swa 空间的使用，以免极大地拉低性能。

设置更长的 flush 时间

我们知道 Kafka 依赖 OS 页缓存的“刷盘”功能实现消息真正写入物理磁盘，默认的刷盘问隔是5秒。通常情况下，这个间隔太短了，适当增加该值可以在很大程度上提升 OS物理写入操作的性能。

Link din 公司自己就将该值设置为2分钟以增加整体的物理写入吞吐量；