kafka参数详解

##broker标识,cluster中,此ID必须唯一  
broker.id=0  
##接受consumer/producer的链接端口  
port=9092  
##用来维护集群状态,以及consumer消费记录  
##consumer和broker必须接入到同一个zk环境中.  
zookeeper.connect=localhost:2181  
zookeeper.connection.timeout.ms=30000  
##broker所能接受的消息的最大尺寸  
##producer不能发布更大尺寸的message  
messages.max.bytes=1000000  
##broker在处理client请求是,允许开启的线程个数.默认为3.  
num.network.threads=3  
##用于磁盘IO操作的线程的个数,默认为8,建议和磁盘的个数保持一致  
num.io.threads=8  
##允许入队的最大请求数,"数据操作请求"首先加入队列,等待IO线程  
##进行磁盘操作获取数据,数据操作结束后,请求被移除队列并由network  
##线程响应给client端.此参数用于控制"等待IO处理的请求数".  
queued.max.requests=500  
#socket调优参数: sendBuffer (SO_SNDBUF)  
socket.send.buffer.bytes=1048576  
##socket调优参数:receiveBuffer (SO_RCVBUFF)  
socket.receive.buffer.bytes=1048576  
# The maximum size of a request that the socket server will accept (protection against OOM)  
socket.request.max.bytes=104857600  
#################Log##########  
log.dirs=/tmp/kafka-logs  
##每个topic的分区数.  
##kafka的特点就在于"分区",每个Topic被拆分成多个partitions  
##partitions可以被sharding到多个broker上,以提高并发能力和"可用性"  
num.partitions=2  
##log文件片段的最大尺寸,每个partition(逻辑上)的数据都会被写入到磁盘的  
##log文件中(append only),此参数用于控制单个文件的大小.  
## 1024*1024*1024,1G  
##log.segment.bytes=  
  
##log文件"sync"到磁盘之前累积的消息条数  
##因为磁盘IO操作是一个慢操作,但又是一个"数据可靠性"的必要手段  
##所以此参数的设置,需要在"数据可靠性"与"性能"之间做必要的权衡.  
##如果此值过大,将会导致每次"fsync"的时间较长(IO阻塞)  
##如果此值过小,将会导致"fsync"的次数较多,这也意味着整体的client请求有一定的延迟.  
##物理server故障,将会导致没有fsync的消息丢失.  
##默认值为10000  
log.flush.interval.messages=10000  
##仅仅通过interval来控制消息的磁盘写入时机,是不足的.  
##此参数用于控制"fsync"的时间间隔,如果消息量始终没有达到阀值,但是离上一次磁盘同步的时间间隔  
##达到阀值,也将触发.  
log.flush.interval.ms=1000  
#对某些特定的topic而言,重写log.flush.interval.messages属性  
##log.flush.intervals.ms.per.topic=topic1:1000, topic2:3000  
  
######################  
##是否自动创建topic  
##如果broker中没有topic的信息,当producer/consumer操作topic时,是否自动创建.  
##如果为false,则只能通过API或者command创建topic  
auto.create.topics.enable=true  
##partition leader与replicas之间通讯时,socket的超时时间  
controller.socket.timeout.ms=30000  
##partition leader与replicas数据同步时,消息的队列尺寸.  
controller.message.queue.size=10  
##partitions的"replicas"个数,不得大于集群中broker的个数  
default.replication.factor=1  
##partition Leader和follower通讯时,如果在此时间内,没有收到follower的"fetch请求"  
##leader将会认为follower"失效",将不会与其同步消息.[follower主动跟随leader,并请求同步消息]  
replica.lag.time.max.ms=10000  
##如果follower落后与leader太多,将会认为此follower[或者说partition relicas]已经失效  
##通常,在follower与leader通讯时,因为网络延迟或者链接断开,总会导致replicas中消息同步滞后  
##如果消息之后太多,leader将认为此follower网络延迟较大或者消息吞吐能力有限,将会把此replicas迁移  
##到其他follower中.  
##在broker数量较少,或者网络不足的环境中,建议提高此值.  
replica.lag.max.messages=4000  
##follower与leader之间的socket超时时间  
replica.socket.timeout.ms=30000  
##1024*1024,follower每次fetch数据的最大尺寸  
##没有意义的参数  
replica.fetch.max.bytes=1048576  
##当follower的fetch请求发出后,等待leader发送数据的时间.  
##超时后,将会重新fetch.  
replica.fetch.wait.max.ms=500  
##fetch的最小数据尺寸,如果leader中尚未同步的数据不足此值,将会阻塞,直到满足条件  
replica.fetch.min.bytes=1  
##follower中开启的fetcher线程数,增加此值可以提高数据同步到速度,但也额外的增加了leader的IO负荷.  
num.replica.fetchers=1  
###########################  
##检测log文件的时间间隔  
log.cleanup.interval.mins=1  
##log文件被保留的时长,如果超过此时长,将会被清除,无论log中的消息是否被消费过.  
log.retention.hours=168

##当前消费者的group名称,需要指定  
##消息的消费进度,是根据group来划定的  
group.id=  
##consumer作为zookeeper client,需要通过zk保存一些meta信息,  
##比如consumer消费的消息offset等.  
##必须和broker使用同样的zk配置  
zookeeper.connect=hostname1:port,hostname2:port2  
zookeeper.session.timeout.ms=6000  
zookeeper.connection.timeout.ms=6000  
zookeeper.sync.time.ms=2000  
##当前consumer的标识,可以设定,也可以有系统生成.  
##主要用来跟踪消息消费情况,便于观察  
conusmer.id=  
##获取消息的最大尺寸,broker不会像consumer输出大于此值的消息chunk  
##每次feth将得到多条消息,此值为总大小  
##提升此值,将会消耗更多的consumer端内存  
fetch.messages.max.bytes=1048576  
##broker发送给consumer的最小数据尺寸,如果消息尺寸不足,将会等待,直到满足.  
fetch.min.bytes=1  
##当消息的尺寸不足时,server阻塞的时间,如果超时,消息将立即发送给consumer.  
fetch.wait.max.ms=100  
queued.max.message.chunks=10  
##当有新的consumer加入到group时,将会reblance,此后将会有partitions的消费端迁移到新  
##的consumer上,如果一个consumer获得了某个partition的消费权限,那么它将会向zk注册  
##"Partition Owner registry"节点信息,但是有可能此时旧的consumer尚没有释放此节点,  
##此值用于控制,注册节点的重试次数.  
rebalance.max.retries=4  
##当consumer消费一定量的消息之后,将会自动向zookeeper提交offset信息  
##注意offset信息并不是每消费一次消息就向zk提交一次,而是现在本地保存(内存),并定期提交  
auto.commit.enable=true  
##自动提交的时间间隔,默认为1分钟.  
auto.commit.interval.ms=60*1000

##对于开发者而言,需要通过broker.list指定当前producer需要关注的broker列表  
##producer通过和每个broker链接,并获取partitions,  
##如果某个broker链接失败,将导致此上的partitons无法继续发布消息  
##格式:host1:port,host2:port2,其中host:port需要参考broker配置文件.  
##对于producer而言没有使用zookeeper自动发现broker列表，非常奇怪。(0.8V和0.7有区别)  
metadata.broker.list=  
##producer接收消息ack的时机.默认为0.  
##0: producer不会等待broker发送ack  
##1: 当leader接收到消息之后发送ack  
##2: 当所有的follower都同步消息成功后发送ack.  
request.required.acks=0  
##在向producer发送ack之前,broker允许等待的最大时间  
##如果超时,broker将会向producer发送一个error ACK.意味着上一次消息因为某种  
##原因未能成功(比如follower未能同步成功)  
request.timeout.ms=10000  
##producer消息发送的模式,同步或异步.  
##异步意味着消息将会在本地buffer,并适时批量发送  
##默认为sync,建议async  
producer.type=sync  
##消息序列化类,将消息实体转换成byte[]  
serializer.class=kafka.serializer.DefaultEncoder  
key.serializer.class=${serializer.class}  
##partitions路由类,消息在发送时将根据此实例的方法获得partition索引号.  
##默认为消息的hashcode % partitions个数  
partitioner.class=kafka.producer.DefaultPartitioner  
  
##消息压缩算法,none,gzip,snappy  
compression.codec=none  
##消息在producer端buffer的条数.仅在producer.type=async下有效  
batch.num.messages=200  
##在async模式下,当message被缓存的时间超过此值后,将会批量发送给broker  
##此值和batch.num.messages协同工作.  
queue.buffering.max.ms=5000  
##在async模式下,producer端允许buffer的最大消息量  
##无论如何,producer都无法尽快的将消息发送给broker,从而导致消息在producer端大量沉积  
##此时,如果消息的条数达到阀值,将会导致producer端阻塞或者消息被抛弃.  
queue.buffering.max.messages=10000  
##当消息在producer端沉积的条数达到"queue.buffering.max.meesages"后  
##阻塞一定时间后,队列仍然没有enqueue(producer仍然没有发送出任何消息)  
##此时producer可以继续阻塞或者将消息抛弃,此timeout值用于控制"阻塞"的时间  
##-1: 无阻塞超时限制,消息不会被抛弃  
##0:立即清空队列,消息被抛弃  
queue.enqueue.timeout.ms=-1  
##当producer接收到error ACK,或者没有接收到ACK时,允许消息重发的次数  
##因为broker并没有完整的机制来避免消息重复,所以当网络异常时(比如ACK丢失)  
##有可能导致broker接收到重复的消息.  
message.send.max.retries=3  
##producer刷新topic metada的时间间隔  
##producer需要知道partition leader的位置,以及当前topic的情况  
##因此producer需要一个机制来获取最新的metadata,当producer遇到特定错误时,将会立即刷新  
##(比如topic失效,partition丢失,leader失效等),此外也可以通过此参数来配置额外的刷新机制  
topic.metadata.refresh.interval.ms=600000