kafka的server.properties配置参数说明

broker.id

每一个broker在集群中的唯一表示，要求是正数。
Kafka在启动时会在zookeeper中/brokers/ids路径下创建一个与当前broker的id为名称的虚节点，Kafka的健康状态检查就依赖于此节点。当broker下线时，该虚节点会自动删除，其他broker或者客户端通过判断/brokers/ids路径下是否有此broker的id来确定该broker的健康状态。

listeners

我们具体说说监听器的概念，从构成上来说，它是若干个逗号分隔的三元组，每个三元组的格式为<协议名称，主机名，端口号>。这里的协议名称可能是标准的名字，比如 PLAINTEXT 表示明文传输、SSL 表示使用 SSL 或 TLS 加密传输等；也可能是你自己定义的协议名字，比如CONTROLLER: //localhost:9092。

一旦你自己定义了协议名称，你必须还要指定listener.security.protocol.map参数告诉这个协议底层使用了哪种安全协议，比如指定

listener.security.protocol.map=CONTROLLER:PLAINTEXT

表示CONTROLLER这个自定义协议底层使用明文不加密传输数据。

advertised.listeners

Advertised 的含义表示宣称的、公布的。生产者或者消费者在外网环境时，需要添加的配置。是暴露给外部的listeners，如果没有设置，会用listeners

num.network.threads

broker处理消息的最大线程数，一般情况下数量为cpu核数

num.io.threads

broker处理磁盘IO的线程数，数值为cpu核数2倍

socket.send.buffer.bytes

socket的发送缓冲区，socket的调优参数SO_SNDBUFF

socket.receive.buffer.bytes

socket的接受缓冲区，socket的调优参数SO_RCVBUFF

socket.request.max.bytes

socket请求的最大数值，防止serverOOM，message.max.bytes必然要小于socket.request.max.bytes，会被topic创建时的指定参数覆盖

log.dirs

用来配置Kafka数据文件存放的根目录，多个路径用逗号分隔，如下所示：
/home/kafka1,/home/kafka2,/home/kafka3
如果有条件的话最好保证这些目录挂载到不同的物理磁盘上。这样做有两个好处：

1. 提升读写性能：比起单块磁盘，多块物理磁盘同时读写数据有更高的吞吐量。
2. 能够实现故障转移：即 Failover。这是 Kafka 1.1 版本新引入的强大功能。要知道在以前，只要 Kafka Broker 使用的任何一块磁盘挂掉了，整个 Broker 进程都会关闭。但是自 1.1 开始，这种情况被修正了，坏掉的磁盘上的数据会自动地转移到其他正常的磁盘上，而且 Broker 还能正常工作。这个改进正是我们舍弃 RAID 方案的基础：没有这种 Failover 的话，只能依靠 RAID 来提供保障。

log.retention.bytes

topic每个分区的最大文件大小，一个topic的大小限制 = 分区数*log.retention.bytes。-1没有大小限log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除，会被topic创建时的指定参数覆盖

log.retention.check.interval.ms

文件大小检查的周期时间，是否触发log.cleanup.policy中设置的策略

log.cleaner.enable

是否开启日志清理

log.retention.hours

控制一条消息数据被保存多长时间
比如log.retention.hours=168表示默认保存 7 天的数据，自动删除 7 天前的数据。很多公司把 Kafka 当做存储来使用，那么这个值就要相应地调大。
这个参数会在日志segment没有达到log.segment.bytes设置的大小，也会强制新建一个segment会被 topic创建时的指定参数覆盖

log.segment.bytes

topic的分区是以一堆segment文件存储的，这个控制每个segment的大小，会被topic创建时的指定参数覆盖
这个值默认是 -1，表明你想在这台 Broker 上保存多少数据都可以，至少在容量方面 Broker 绝对为你开绿灯，不会做任何阻拦。这个参数真正发挥作用的场景其实是在云上构建多租户的 Kafka 集群：设想你要做一个云上的 Kafka 服务，每个租户只能使用 100GB 的磁盘空间，为了避免有个“恶意”租户使用过多的磁盘空间，设置这个参数就显得至关重要了。

log.cleanup.policy

日志清理策略选择有：delete和compact主要针对过期数据的处理，或是日志文件达到限制的额度，会被 topic创建时的指定参数覆盖
log.retention.bytes和log.retention.minutes或log.retention.hours任意一个达到要求，都会执行删除

message.max.bytes

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

controller.socket.timeout.ms

partition leader与replicas之间通讯时,socket的超时时间

replica.lag.time.max.ms

replicas响应partition leader的最长等待时间，若是超过这个时间，就将replicas列入ISR(in-sync replicas)，并认为它是死的，不会再加入管理中

replica.lag.max.messages

在broker数量较少,或者网络不足的环境中,建议提高此值

replica.fetch.wait.max.ms

replicas同leader之间通信的最大等待时间，失败了会重试

zookeeper.connect

zookeeper连接地址
zookeeper.connect : 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

zookeeper.session.timeout.ms

ZooKeeper的最大超时时间，就是心跳的间隔，若是没有反映，那么认为已经死了，不易过大

zookeeper.connection.timeout.ms

ZooKeeper的连接超时时间

zookeeper.sync.time.ms

ZooKeeper集群中leader和follower之间的同步时间

Topic 级别参数的设置

• 创建 Topic 时进行设置

 需要保存最近半年的交易数据，最大传输数据为 5MB。
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

• 修改 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 参数

• 堆内存设置
  将JVM 堆大小设置成 6GB , 目前业界比较公认的一个合理值.默认的 1GB 有点小，毕竟 Kafka Broker 在与客户端进行交互时会在 JVM 堆上创建大量的 ByteBuffer 实例，Heap Size 不能太小。

• GC的设置
  推荐使用 G1 收集器

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

操作系统参数

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

参考链接
https://zhangboyi.blog.csdn.net/article/details/103661629
https://blog.51cto.com/u_12445535/2437635