Service.properties参数详解

Service.properties参数详解

server.properties是Kafka的主要配置文件，下面简单介绍其中的相关配置项的含义。通常最为核心的三个配置 broker.id、log.dir、zookeeper.connect 。其余配置能够根据需求自行修改。

进入配置目录，一般相关的配置主要有如下三个

 

 其余配置以下：

 

Service.properties参数详解
参数		功能描述		使用建议
broker.id=0		每个Broker在集群中的惟标识。即便Broker的IP地址发生了变化，broker.id只要没变，则不会影响consumers的消息状况		不通broker需修改为不一样的Id,通常是一个整数
log.dirs=/data/kafka-logs		kafka数据的存放地址，多个地址的话用逗号分割,多个目录分布在不一样磁盘上能够提升读写性能  /data/kafka-logs-1，/data/kafka-logs-2		通常状况下须要根据使用进行目录修改
port =9092		broker server服务端口
message.max.bytes =6525000		表示消息体的最大大小，单位是字节
num.network.threads =4		broker处理消息的最大线程数，通常状况下数量为cpu核数
num.io.threads =8		broker处理磁盘IO的线程数，数值为cpu核数2倍
background.threads =4		一些后台任务处理的线程数，例如过时消息文件的删除等，通常状况下不须要去作修改
queued.max.requests =500		等待IO线程处理的请求队列最大数，如果等待IO的请求超过这个数值，那么会中止接受外部消息，应该是一种自我保护机制。
host.name		broker的主机地址，如果设置了，那么会绑定到这个地址上，如果没有，会绑定到全部的接口上，并将其中之一发送到ZK，通常不设置
socket.send.buffer.bytes=100*1024		socket的发送缓冲区，socket的调优参数SO_SNDBUFF
socket.receive.buffer.bytes =100*1024		socket的接受缓冲区，socket的调优参数SO_RCVBUFF
socket.request.max.bytes =100*1024*1024		socket请求的最大数值，防止serverOOM，message.max.bytes必然要小于socket.request.max.bytes，会被topic建立时的指定参数覆盖
log.segment.bytes =1024*1024*1024		topic的分区是以一堆segment文件存储的，这个控制每一个segment的大小，会被topic建立时的指定参数覆盖		日志分段大小
log.roll.hours =24*7		这个参数会在日志segment没有达到log.segment.bytes设置的大小，也会强制新建一个segment会被 topic建立时的指定参数覆盖
log.cleanup.policy = delete		日志清理策略选择有：delete和compact主要针对过时数据的处理，或是日志文件达到限制的额度，会被 topic建立时的指定参数覆盖
log.retention.minutes=300 log.retention.hours=24		数据文件保留多长时间， 存储的最大时间超过这个时间会根据log.cleanup.policy设置数据清除策略 log.retention.bytes和log.retention.minutes或log.retention.hours任意一个达到要求，都会执行删除 有2删除数据文件方式：   按照文件大小删除：log.retention.bytes   按照2中不一样时间粒度删除：分别为分钟，小时
log.retention.bytes=-1		topic每一个分区的最大文件大小，一个topic的大小限制 = 分区数*log.retention.bytes。-1没有大小限log.retention.bytes和log.retention.minutes任意一个达到要求，都会执行删除，会被topic建立时的指定参数覆盖		必须限制日志文件的最大大小，防止出现日志占满磁盘的状况
log.retention.check.interval.ms=5minutes		文件大小检查的周期时间，是否处罚 log.cleanup.policy中设置的策略
log.cleaner.enable=false		是否开启日志清理
log.cleaner.threads = 2		日志清理运行的线程数
log.cleaner.io.max.bytes.per.second=None		日志清理时候处理的最大大小
log.cleaner.dedupe.buffer.size=500*1024*1024		日志清理去重时候的缓存空间，在空间容许的状况下，越大越好
log.cleaner.io.buffer.size=512*1024		日志清理时候用到的IO块大小通常不须要修改
log.cleaner.io.buffer.load.factor =0.9		日志清理中hash表的扩大因子通常不须要修改
log.cleaner.backoff.ms =15000		检查是否处罚日志清理的间隔
log.cleaner.min.cleanable.ratio=0.5		日志清理的频率控制，越大意味着更高效的清理，同时会存在一些空间上的浪费，会被topic建立时的指定参数覆盖
log.cleaner.delete.retention.ms =1day		对于压缩的日志保留的最长时间，也是客户端消费消息的最长时间，同log.retention.minutes的区别在于一个控制未压缩数据，一个控制压缩后的数据。会被topic建立时的指定参数覆盖
log.index.size.max.bytes =10*1024*1024		对于segment日志的索引文件大小限制，会被topic建立时的指定参数覆盖
log.index.interval.bytes =4096		当执行一个fetch操做后，须要必定的空间来扫描最近的offset大小，设置越大，表明扫描速度越快，可是也更好内存，通常状况下不须要搭理这个参数
log.flush.interval.messages=None 例如log.flush.interval.messages=1000 表示每当消息记录数达到1000时flush一次数据到磁盘		log文件”sync”到磁盘以前累积的消息条数,由于磁盘IO操做是一个慢操做,但又是一个”数据可靠性"的必要手段,因此此参数的设置,须要在"数据可靠性"与"性能"之间作必要的权衡.若是此值过大,将会致使每次"fsync"的时间较长(IO阻塞),若是此值太小,将会致使"fsync"的次数较多,这也意味着总体的client请求有必定的延迟.物理server故障,将会致使没有fsync的消息丢失.
log.flush.scheduler.interval.ms =3000		检查是否须要固化到硬盘的时间间隔
log.flush.interval.ms = None 例如：log.flush.interval.ms=1000 表示每间隔1000毫秒flush一次数据到磁盘		仅仅经过interval来控制消息的磁盘写入时机,是不足的.此参数用于控制"fsync"的时间间隔,若是消息量始终没有达到阀值,可是离上一次磁盘同步的时间间隔达到阀值,也将触发.
log.delete.delay.ms =60000		文件在索引中清除后保留的时间通常不须要去修改
log.flush.offset.checkpoint.interval.ms =60000		控制上次固化硬盘的时间点，以便于数据恢复通常不须要去修改
auto.create.topics.enable =true		是否容许自动建立topic，如果false，就须要经过命令建立topic
default.replication.factor =1		一个topic ，默认分区的replication个数 ，不得大于集群中broker的个数
num.partitions =1		每一个topic的分区个数，如果在topic建立时候没有指定的话会被topic建立时的指定参数覆盖
controller.socket.timeout.ms =30000		partition leader与replicas之间通信时,socket的超时时间
controller.message.queue.size=10		partition leader与replicas数据同步时,消息的队列尺寸
replica.lag.time.max.ms =10000		replicas响应partition leader的最长等待时间，如果超过这个时间，就将replicas列入ISR(in-sync replicas)，并认为它是死的，不会再加入管理中
replica.lag.max.messages =4000		若是follower落后与leader太多,将会认为此follower[或者说partition relicas]已经失效 ##一般,在follower与leader通信时,由于网络延迟或者连接断开,总会致使replicas中消息同步滞后 ##若是消息以后太多,leader将认为此follower网络延迟较大或者消息吞吐能力有限,将会把此replicas迁移 ##到其余follower中. ##在broker数量较少,或者网络不足的环境中,建议提升此值.
replica.socket.timeout.ms=30*1000		follower与leader之间的socket超时时间
replica.socket.receive.buffer.bytes=64*1024		leader复制时候的socket缓存大小
replica.fetch.max.bytes =1024*1024		replicas每次获取数据的最大大小
replica.fetch.wait.max.ms =500		replicas同leader之间通讯的最大等待时间，失败了会重试
replica.fetch.min.bytes =1		fetch的最小数据尺寸,若是leader中还没有同步的数据不足此值,将会阻塞,直到知足条件
num.replica.fetchers=1		leader进行复制的线程数，增大这个数值会增长follower的IO
replica.high.watermark.checkpoint.interval.ms =5000		每一个replica检查是否将最高水位进行固化的频率
controlled.shutdown.enable =false		是否容许控制器关闭broker ,如果设置为true,会关闭全部在这个broker上的leader，并转移到其余broker
controlled.shutdown.max.retries =3		控制器关闭的尝试次数
controlled.shutdown.retry.backoff.ms =5000		每次关闭尝试的时间间隔
leader.imbalance.per.broker.percentage =10		leader的不平衡比例，如果超过这个数值，会对分区进行从新的平衡
leader.imbalance.check.interval.seconds =300		检查leader是否不平衡的时间间隔
offset.metadata.max.bytes		客户端保留offset信息的最大空间大小
zookeeper.connect = localhost:2181		zookeeper集群的地址，能够是多个，多个之间用逗号分割hostname1:port1,hostname2:port2,hostname3:port3
zookeeper.session.timeout.ms=6000		ZooKeeper的最大超时时间，就是心跳的间隔，如果没有反映，那么认为已经死了，不易过大
zookeeper.connection.timeout.ms =6000		ZooKeeper的链接超时时间
zookeeper.sync.time.ms =2000		ZooKeeper集群中leader和follower之间的同步时间
consumer.properties参数详解
参数	功能描述		使用建议
group.id	Consumer归属的组ID，broker是根据group.id来判断是队列模式仍是发布订阅模式，很是重要
consumer.id	消费者的ID，如果没有设置的话，会自增
client.id = group id value	一个用于跟踪调查的ID ，最好同group.id相同
zookeeper.connect=localhost:2182	对于zookeeper集群的指定，能够是多个 hostname1:port1,hostname2:port2,hostname3:port3 必须和broker使用一样的zk配置
zookeeper.session.timeout.ms = 6000	zookeeper的心跳超时时间，查过这个时间就认为是dead消费者
zookeeper.connection.timeout.ms = 6000	zookeeper的等待链接时间
zookeeper.sync.time.ms = 2000	zookeeper的follower同leader的同步时间
auto.offset.reset = largest	当zookeeper中没有初始的offset时候的处理方式 。smallest ：重置为最小值 largest:重置为最大值 anything else：抛出异常
socket.timeout.ms= 30 * 1000	socket的超时时间，实际的超时时间是：max.fetch.wait + socket.timeout.ms.
socket.receive.buffer.bytes=64 * 1024	socket的接受缓存空间大小
fetch.message.max.bytes = 1024 * 1024	从每一个分区获取的消息大小限制
auto.commit.interval.ms = 60 * 1000	自动提交的时间间隔
queued.max.message.chunks = 10	用来处理消费消息的块，每一个块能够等同于fetch.message.max.bytes中数值
rebalance.max.retries = 4	## 当有新的consumer加入到group时,将会reblance,此后将会有partitions的消费端迁移到新的consumer上,若是一个consumer得到了某个partition的消费权限,那么它将会向zk注册"Partition Owner registry"节点信息,可是有可能此时旧的consumer尚没有释放此节点, ## 此值用于控制,注册节点的重试次数.
rebalance.backoff.ms = 2000	每次再平衡的时间间隔
refresh.leader.backoff.ms	每次从新选举leader的时间
fetch.min.bytes = 1	server发送到消费端的最小数据，如果不知足这个数值则会等待，知道知足数值要求
fetch.wait.max.ms = 100	如果不知足最小大小(fetch.min.bytes)的话，等待消费端请求的最长等待时间
consumer.timeout.ms = -1	指定时间内没有消息到达就抛出异常，通常不须要改

 

 

producer.properties参数详解
参数	功能描述	使用建议
metadata.broker.list	消费者获取消息元信息(topics, partitions and replicas)的地址,配置格式是：host1:port1,host2:port2，也能够在外面设置一个vip
request.required.acks = 0	##消息的确认模式  ## 0：不保证消息的到达确认，只管发送，低延迟可是会出现消息的丢失，在某个server失败的状况下，有点像TCP  ## 1：发送消息，并会等待leader 收到确认后，必定的可靠性  ## -1：发送消息，等待leader收到确认，并进行复制操做后，才返回，最高的可靠性
request.timeout.ms = 10000	消息发送的最长等待时间
send.buffer.bytes=100*1024	socket的缓存大小
key.serializer.class	key的序列化方式，如果没有设置，同serializer.class
partitioner.class=kafka.producer.DefaultPartitioner	分区的策略，默认是取模
compression.codec = none	消息的压缩模式，默认是none，能够有gzip和snappy
compressed.topics=null	能够针对默写特定的topic进行压缩
message.send.max.retries = 3	消息发送失败后的重试次数
retry.backoff.ms = 100	每次失败后的间隔时间
topic.metadata.refresh.interval.ms = 600 * 1000	生产者定时更新topic元信息的时间间隔 ，如果设置为0，那么会在每一个消息发送后都去更新数据
client.id=""	用户随意指定，可是不能重复，主要用于跟踪记录消息
producer.type=sync	生产者的类型 async:异步执行消息的发送 sync：同步执行消息的发送
queue.buffering.max.ms = 5000	异步模式下，那么就会在设置的时间缓存消息，并一次性发送
queue.buffering.max.messages = 10000	异步的模式下 最长等待的消息数
queue.enqueue.timeout.ms = -1	异步模式下，进入队列的等待时间 如果设置为0，那么要么进入队列，要么直接抛弃
batch.num.messages=200	异步模式下，每次发送的最大消息数，前提是触发了queue.buffering.max.messages或是queue.buffering.max.ms的限制
serializer.class = kafka.serializer.DefaultEncoder	消息体的系列化处理类 ，转化为字节流进行传输

 

 

参考：

https://blog.csdn.net/selfsojourner/article/details/44957135

https://blog.csdn.net/lizhitao/article/details/25667831