本文主要是介绍kafka的server.properties配置参数说明,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
kafka的server.properties配置参数说明
- broker.id
- listeners
- advertised.listeners
- num.network.threads
- num.io.threads
- socket.send.buffer.bytes
- socket.receive.buffer.bytes
- socket.request.max.bytes
- log.dirs
- log.retention.bytes
- log.retention.check.interval.ms
- log.cleaner.enable
- log.retention.hours
- log.segment.bytes
- log.cleanup.policy
- message.max.bytes
- controller.socket.timeout.ms
- replica.lag.time.max.ms
- replica.lag.max.messages
- replica.fetch.wait.max.ms
- zookeeper.connect
- zookeeper.session.timeout.ms
- zookeeper.connection.timeout.ms
- zookeeper.sync.time.ms
- Topic 级别参数的设置
- JVM 参数
- 操作系统参数
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
如果有条件的话最好保证这些目录挂载到不同的物理磁盘上。这样做有两个好处:
- 提升读写性能:比起单块磁盘,多块物理磁盘同时读写数据有更高的吞吐量。
- 能够实现故障转移:即 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
操作系统参数
- 文件描述符限制
文件句柄数 ulimit -n
通常情况下将它设置成一个超大的值是合理的做法,比如ulimit -n 1000000。
如果设置的不够大的话,会抛出异常: Too many open files - 文件系统类型
XFS 的性能要强于 ext4,所以生产环境最好还是使用 XFS。
据说 ZFS 性能更强,可以考虑试试.
测试报告: https://www.confluent.io/kafka-summit-sf18/kafka-on-zfs - Swappiness
网上很多文章都提到设置其为 0,将 swap 完全禁掉以防止 Kafka 进程使用 swap 空间。推荐设置成一个较小的值。为什么呢?因为一旦设置成 0,当物理内存耗尽时,操作系统会触发 OOM killer 这个组件,它会随机挑选一个进程然后 kill 掉,即根本不给用户任何的预警。但如果设置成一个比较小的值,当开始使用 swap 空间时,你至少能够观测到 Broker 性能开始出现急剧下降,从而给你进一步调优和诊断问题的时间。基于这个考虑, 建议将 swappniess 配置成一个接近 0 但不为 0 的值,比如 1。 - 提交时间/Flush 落盘时间
向 Kafka 发送数据并不是真要等数据被写入磁盘才会认为成功,而是只要数据被写入到操作系统的页缓存(Page Cache)上就可以了,随后操作系统根据 LRU 算法会定期将页缓存上的“脏”数据落盘到物理磁盘上。这个定期就是由提交时间来确定的,默认是 5 秒。一般情况下我们会认为这个时间太频繁了,可以适当地增加提交间隔来降低物理磁盘的写操作。当然你可能会有这样的疑问:如果在页缓存中的数据在写入到磁盘前机器宕机了,那岂不是数据就丢失了。的确,这种情况数据确实就丢失了,但鉴于 Kafka 在软件层面已经提供了多副本的冗余机制,因此这里稍微拉大提交间隔去换取性能还是一个合理的做法。
参考链接
https://zhangboyi.blog.csdn.net/article/details/103661629
https://blog.51cto.com/u_12445535/2437635
这篇关于kafka的server.properties配置参数说明的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!