kafka参数详解

转自：http://shift-alt-ctrl.iteye.com/blog/1930345

1.Broker主要配置

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

2 Consumer主要配置

  

##当前消费者的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  

3 .Producer主要配置

##对于开发者而言,需要通过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