标签：常用 log bytes broker Kafka topic 参数 日志 leader
# ----------------------系统相关----------------------
# broker的全局唯一编号，不能重复，和zookeeper的myid是一个意思
broker.id=0
# broker监听IP和端口也可以是域名
listeners=PLAINTEXT://172.16.48.163:9092
# 这个配置方式和listeners相同，主要用于Kafka有多个IP地址，比如内网和外网，下面这个用于配置外部连接使用的地址
# 如果不配置，则该参数值和listeners相同
advertised.listeners=PLAINTEXT://10.10.2.37:9092
# 配置ZK连接地址，后面的/kafak是为了指定ZK的路径，也可以不设置，但如果有多套
# kafka集群，为了区分还是要设置路径
zookeeper.connect=zk01:2181,zk02:2181,zk03:2181/kafka
# 用于控制broker接收网络请求的线程数量，默认是3.这个参数控制的线程是用来处理来自其他broker和client发来的各种请求。
# 我们需要监控NetworkProcessorAvgIdlePercent这个JMX参数，如果小于0.5则要考虑加大这个值。
num.network.threads=3
# 用于实际处理请求的线程数量，默认是8个线程，这8个线程通过轮询的方式来处理num.network.threads线程转发过来的请求。
# JMX指标HandlerAvgIdlePercent如果持续小于0.5，我们就要考虑增加这个值。
num.io.threads=8
# 发送缓冲区大小，也就是说发送消息先发送到缓冲区，当缓冲区满了之后一起发送出去
socket.send.buffer.bytes=102400
# 接收缓冲区大小，同理接收到缓冲区，当到达这个数量时就同步到磁盘
socket.receive.buffer.bytes=102400
# 向kafka套接字请求最大字节数量，防止服务器OOM，也就是OutOfMemery，这个数量不要超过JAVA的堆栈大小，
socket.request.max.bytes=104857600
# 数据存储路径，没有默认值，可以设置一个路径，但推荐设置多个,要保证每个目录都是
# 单独的一个磁盘，这样保证性能。
log.dirs=/data/kafka_data1,/data/kafka_data2,/data/kafka_data3
# 消息体（也就是往Kafka发送的单条消息）最大大小，单位是字节，必须小于socket.request.max.bytes值，默认977KB。
message.max.bytes =5000000
# 自动平衡由于某个broker故障会导致Leader副本迁移到别的broker，当之前的broker恢复后也不会迁移回来，有时候我们需要
# 手动进行平衡避免同一个主题不同分区的Leader副本在同一台broker上，下面这个参数就是开启自动平衡功能
auto.leader.rebalance.enable=true
# 设置了上面的自动平衡，当故障转移后，隔300秒（默认）触发一个定时任务进行平衡操作，而只有代理的不均衡率为10%以上才会执行
leader.imbalance.check.interval.seconds=300
# 是否允许从非ISR副本中选择Leader，默认值是false
unclean.leader.election.enable=false
# 设置代理的不均衡率，默认是10%
leader.imbalance.per.broker.percentage=10
# 是否允许Kafka删除topic。
delete.topic.enable=true
# ---------------分区相关-------------------------
# 默认分区数量，当建立Topic时不指定分区数量，默认就1
num.partitions=1
# 是否允许自动创建topic ，若是false，就需要通过命令创建topic，建议关闭，防止误建立没用的主题
auto.create.topics.enable=false
# 一个topic ，默认分区的replication个数 ，不得大于集群中broker的个数，这个值是包括Leader副本和Follower副本的数量。
default.replication.factor=3
# ---------------日志相关-------------------------
# segment文件默认会被保留7天的时间，超时的话就会被清理，那么清理这件事情就需要有一些线程来做。
# 这里就是用来设置恢复和清理data下数据的线程数量
num.recovery.threads.per.data.dir=1
# 日志文件中每个segment的大小，默认为1G。topic的分区是以一堆segment文件存储的，这个控制每个segment的大小，当超过这个大小会建立一个新日志文件
# 这个参数会被topic创建时的指定参数覆盖，如果你创建Topic的时候指定了这个参数，那么你以你指定的为准。达到这个大小会进行日志切割，并不会删除日志。
log.segment.bytes=1073741824
# 数据存储的最大时间 超过这个时间 会根据log.cleanup.policy设置的策略处理数据，也就是消费端能够多久去消费数据
# log.retention.bytes和log.retention.minutes|hours任意一个达到要求，都会执行删除
# 如果你创建Topic的时候指定了这个参数，那么你以你指定的为准。默认是保留7天。
log.retention.hours|minutes=168
# 每个topic的每个分区保存的数据总量，这是每个分区日志文件的上限，这个数值乘以分区数量就是每个topic的数据总量。
log.retention.bytes=-1
# 这个参数会在日志segment没有达到log.segment.bytes设置的大小默认1G的时候，也会强制新建一个segment，也就是日志切割。该参数会被
# topic创建时的指定参数覆盖，该参数根据日志文件创建时间这个数据来判断
log.roll.hours=168
# 上面的参数设置了每一个segment文件的大小是1G，那么就需要有一个东西去定期检查segment文件有没有达到1G，多长时间去检查一次，
# 就需要设置一个周期性检查文件大小的时间（单位是毫秒）。
log.retention.check.interval.ms=300000
# 日志清理策略 选择有：delete和compact 是针对过期数据的处理，或是日志文件达到限制的额度，
# 如果你创建Topic的时候指定了这个参数，那么你以你指定的为准
log.cleanup.policy = delete
# 是否启用日志清理功能，默认是启用的且清理策略为compact，也就是压缩。
log.cleaner.enable=false
# 日志清理时所使用的缓存空间大小
log.cleaner.dedupe.buffer.size=134217728
# 消息达到多少条时将数据写入到日志文件，但这只是控制从内存写入日志这个操作是否触发，因为触发这个操作
# 只是把数据从用户空间拷贝到内核空间，并不是真正的写入磁盘，因为Linux是延迟写入，至于什么时候真正写入
# 则是操作系统控制
log.flush.interval.messages=10000000
# 检查是否需要写入磁盘的频率，上面设置了一个值，总需要一个检测器定期检查是否达到阈值，这里的参数就是设置
# 检查器检查的频率
log.flush.scheduler.interval.ms=3000
# 这个是把数据从内存写入磁盘的频率，log.flush.interval.messages等于是空间维度的，这个是时间维度的
# 其实都是触发写入磁盘的动作，也就是完成用户空间数据到内核空间的拷贝，真正写磁盘还是操作系统来决定，
# 操作系统内部有一个频率就是定期执行sync操作用于同步内存到磁盘的数据。
log.flush.interval.ms=None
# 日志的索引文件大小
log.index.size.max.bytes=
# 索引文件采取的是稀疏索引，也就意味着不是每条消息都会有对应的索引，这个参数就是设置每隔多少字节消息建立一个索引记录。
log.index.interval.bytes=4096
# -------------------------- __consumer_offets 主题 相关-------------------
# 设置__consumer_offets主题的副本数量，默认是1
offsets.topic.replication.factor=3
# --------------------------复制(Leader、replicas) 相关-------------------
# partition leader与replicas之间通讯时,socket的超时时间
controller.socket.timeout.ms =30000
# replicas响应partition leader的最长等待时间，若是超过这个时间，就将replicas列入ISR(in-sync replicas)，
# 并认为它是死的，不会再加入管理中
replica.lag.time.max.ms =10000
# follower与leader之间的socket超时时间
replica.socket.timeout.ms=300000
# leader复制时候的socket缓存大小
replica.socket.receive.buffer.bytes=65536
# replicas每次获取数据的最大大小
replica.fetch.max.bytes =1048576
# replicas同leader之间通信的最大等待时间，失败了会重试
replica.fetch.wait.max.ms =500
# fetch的最小数据尺寸,如果leader中尚未同步的数据不足此值,将会阻塞,直到满足条件
replica.fetch.min.bytes =1
# leader 进行复制的线程数，增大这个数值会增加follower的IO
num.replica.fetchers=1
# 服务端响应客户后的最小副本数量，该参数在acks=-1才有效。该参数指定最少有几个副本同步了消息服务端才对客户端写入的消息做出写入成功响应。
min.insync.replicas = 2
标签：常用,log,bytes,broker,Kafka,topic,参数,日志,leader 来源： https://www.cnblogs.com/yinging/p/16512830.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。