文章转载自:http://liyonghui160com.iteye.com/blog/2163899

server.properties配置:

server.properties中所有配置参数说明(解释)如下列表:

参数

说明(解释)

broker.id =0

每一个broker在集群中的唯一表示,

要求是正数。当该服务器的IP地址

发生改变时,broker.id没有变化,

则不会影响consumers的消息情况

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处理消息的最大线程数,

一般情况下不需要去修改

num.io.threads =8

broker处理磁盘IO的线程数,

数值应该大于你的硬盘数

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=3days

数据存储的最大时间超过这个时间会

根据log.cleanup.policy设置的

策略处理数据,也就是消费端

能够多久去消费数据

log.retention.bytes和

log.retention.minutes

任意一个达到要求,都会执行删除,

会被topic创建时的指定参数覆盖

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文件”sync”到磁盘之前累积的消息条数,

因为磁盘IO操作是一个慢操作,

但又是一个”数据可靠性"的必要手段,

所以此参数的设置,需要在"数据可靠性"

与"性能"之间做必要的权衡.如果此值过大,

将会导致每次"fsync"的时间较长(IO阻塞),

如果此值过小,将会导致"fsync"的次数较多,

这也意味着整体的client请求有一定的延迟.

物理server故障,将会导致没有fsync的消息丢失.

log.flush.scheduler.interval.ms =3000

检查是否需要固化到硬盘的时间间隔

log.flush.interval.ms = None

仅仅通过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

副本的个数

num.partitions =1

每个topic的分区个数,若是在topic

创建时候没有指定的话会被topic

创建时的指定参数覆盖

   

以下是kafka中Leader,replicas配置参数

 

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信息的最大空间大小

kafka中zookeeper参数配置

 

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之间的同步实际那

0.8.1版server.properties配置

broker.id  默认值:无

每一个broker都有一个唯一的id,这是一个非负整数,这个id就是broker的"名字",这样就允许broker迁移到别的机器而不会影响消费者。你可以选择任意一个数字,只要它是唯一的。

log.dirs 默认值:/tmp/kafka-logs

一个用逗号分隔的目录列表,可以有多个,用来为Kafka存储数据。每当需要为一个新的partition分配一个目录时,会选择当前的存储partition最少的目录来存储。

port 默认值:6667

server用来接受client请求的端口。

zookeeper.connect 默认值:null

指定了ZooKeeper的connect string,以hostname:port的形式,hostname和port就是ZooKeeper集群各个节点的hostname和port。 ZooKeeper集群中的某个节点可能会挂掉,所以可以指定多个节点的connect string。如下所式:

hostname1:port1,hostname2:port2,hostname3:port3 .

ZooKeeper也可以允许你指定一个"chroot"的路径,可以让Kafka集群将需要存储在ZooKeeper的数据存储到指定的路径下这可以让多个Kafka集群或其他应用程序公用同一个ZooKeeper集群。可以使用如下的connect string:

hostname1:port1,hostname2:port2,hostname3:port3/chroot/path

这样就可以讲这个集群的所有数据存放在/chroot/path路径下。注意在启动集群前,一定要先自己创建这个路径,consumer也得使用相同的connect string。

message.max.bytes 默认值:1000000

server能接收的一条消息的最大的大小。这个属性跟consumer使用的最大fetch大小是一致的,这很重要,否则一个不守规矩的producer会发送一个太大的消息。

num.network.threads 默认值:3

处理网络的线程的数量,server端用来处理网络请求,一般不需要改变它。

num.io.threads 默认值:8

server端处理请求时的I/O线程的数量,不要小于磁盘的数量。

background.threads 默认值:4

用来处理各种不同的后台任务的线程数量,比如删除文件,一般不需要改变它。

queued.max.requests 默认值:500

I/O线程等待队列中的最大的请求数,超过这个数量,network线程就不会再接收一个新的请求。

host.name 默认值:null

broker的hostname,如果设置了它,会仅绑定这个地址。如果没有设置,则会绑定所有的网络接口,并提交一个给ZK。

advertised.host.name 默认值:null

如果设置了这个hostname,会分发给所有的producer,consumer和其他broker来连接自己。

advertised.port 默认值:null

分发这个端口给所有的producer,consumer和其他broker来建立连接。如果此端口跟server绑定的端口不同,则才有必要设置。

socket.send.buffer.bytes 默认值:100 * 1024

server端用来处理socket连接的SO_SNDBUFF缓冲大小。

socket.receive.buffer.bytes 默认值:100 * 1024

server端用来处理socket连接的SO_RCVBUFF缓冲大小。

socket.request.max.bytes 默认值:100 * 1024 * 1024

server能接受的请求的最大的大小,这是为了防止server跑光内存,不能大于Java堆的大小。

num.partitions 默认值:1

如果在创建topic的时候没有指定partition的数量,则使用这个值来设置。

log.segment.bytes 默认值:1024 * 1024 * 1024

一个topic的一个partition对应的所有segment文件称为log。这个设置控制着一个segment文件的最大的大小,如果超过了此大小,就会生成一个新的segment文件。此配置可以被覆盖,参考 the per-topic configuration section。

log.roll.hours 默认值:24 * 7

这个设置会强制Kafka去roll一个新的log segment文件,即使当前使用的segment文件的大小还没有超过log.segment.bytes。此配置可以被覆盖,参考 the per-topic configuration section。

log.cleanup.policy 默认值:delete

此配置可以设置成delete或compact。如果设置为delete,当log segment文件的大小达到上限,或者roll时间达到上限,文件将会被删除。如果设置成compact,则此文件会被清理,标记成已过时状态,详见 log compaction 。此配置可以被覆盖,参考 the per-topic configuration section。

log.retention.minutes 默认值:7 days

在删除log文件之前,保存在磁盘的时间,单位为分钟,这是所有topic的默认值。注意如果同时设置了log.retention.minutes和 log.retention.bytes,如果达到任意一个条件的限制,都会马上删掉。此配置可以被覆盖,参考 the per-topic configuration section。

log.retention.bytes 默认值:-1

topic每个分区的最大文件大小,一个topic的大小限制 = 分区数 * log.retention.bytes。-1没有大小限log.retention.bytes和log.retention.minutes任意一个 达到要求,都会执行删除。此配置可以被覆盖,参考 the per-topic configuration section。

log.retention.check.interval.ms 默认值:5 minutes

检查任意一个log segment文件是否需要进行retention处理的时间间隔。

log.cleaner.enable 默认值:false

设置为true就开启了log compaction功能。

log.cleaner.threads 默认值:1

使用log compaction功能来清理log的线程的数量。

log.cleaner.io.max.bytes.per.second 默认值:None

在执行log compaction的过程中,限制了cleaner每秒钟I/O的数据量,以免cleaner影响正在执行的请求。

log.cleaner.dedupe.buffer.size 默认值:500 * 1024 * 1024

日志压缩去重时候的缓存空间,在空间允许的情况下,越大越好。

log.cleaner.io.buffer.size 默认值:512 * 1024

日志清理时候用到的I/O块(chunk)大小,一般不需要修改。

log.cleaner.io.buffer.load.factor 默认值:0.9

日志清理中hash表的扩大因子,一般不需要修改。

log.cleaner.backoff.ms 默认值:15000

检查log是否需要clean的时间间隔。

log.cleaner.min.cleanable.ratio 默认值:0.5

控制了log compactor进行clean操作的频率。默认情况下,当log的50%以上已被clean时,就不用继续clean了。此配置可以被覆盖,参考 the per-topic configuration section。

log.cleaner.delete.retention.ms 默认值:1 day

对于压缩的日志保留的最长时间,也是客户端消费消息的最长时间,同log.retention.minutes的区别在于一个控制未压缩数据,一个控制压缩后的数据,参考 the per-topic configuration section。

log.index.size.max.bytes 默认值:10 * 1024 * 1024

每一个log segment文件的offset index文件的最大的size。注意总是预分配一个稀疏(sparse)文件,当roll这个文件时再shrink down。如果index文件被写满,那么就roll一个新的log segment文件,即使还没达到log.segment.byte限制。参考 the per-topic configuration section。

log.index.interval.bytes 默认值:4096

当执行一个fetch操作后,需要一定的空间来扫描最近的offset大小,设置越大,代表扫描速度越快,但是也更耗内存,一般情况下不需要改变这个参数。

log.flush.interval.messages 默认值:None

在强制fsync一个partition的log文件之前暂存的消息数量。调低这个值会更频繁的sync数据到磁盘,影响性能。通常建议人家使用replication来确保持久性,而不是依靠单机上的fsync,但是这可以带来更多的可靠性。

log.flush.scheduler.interval.ms 默认值:3000

log flusher检查是否需要把log刷到磁盘的时间间隔,单位为ms。

log.flush.interval.ms 默认值:None

2次fsync调用之间最大的时间间隔,单位为ms。即使log.flush.interval.messages没有达到,只要这个时间到了也需要调用fsync。

log.delete.delay.ms 默认值:60000

在log文件被移出索引后,log文件的保留时间。在这段时间内运行的任意正在进行的读操作完成操作,不用去打断它。通常不需要改变。

log.flush.offset.checkpoint.interval.ms 默认值:60000

记录上次把log刷到磁盘的时间点的频率,用来日后的recovery。通常不需要改变。

auto.create.topics.enable 默认值:true

是否允许自动创建topic。如果设为true,那么produce,consume或者fetch metadata一个不存在的topic时,就会自动创建一个默认replication factor和partition number的topic。

controller.socket.timeout.ms 默认值:30000

partition管理控制器发向replica的命令的socket超时时间。

controller.message.queue.size 默认值:10

partition leader与replicas数据同步时的消息的队列大小。

default.replication.factor 默认值:1

自动创建topic时的默认replication factor的(副本)个数。

replica.lag.time.max.ms 默认值:10000

如果一个follower在有一个时间窗口内没有发送任意fetch请求,leader就会把这个follower从ISR(in-sync replicas)移除,并认为它已挂掉。

replica.lag.max.messages 默认值:4000

如果一个replica落后leader此配置指定的消息条数,leader就会把它移除ISR,并认为它挂掉。

replica.socket.timeout.ms 默认值:300 * 1000

复制数据过程中,replica发送给leader的网络请求的socket超时时间。

replica.socket.receive.buffer.bytes 默认值:64 * 1024

复制数据过程中,replica发送网络请求给leader的socket receiver buffer的大小。

replica.fetch.max.bytes 默认值:1024 * 1024

复制数据过程中,replica发送给leader的fetch请求试图获取数据的最大的字节数。

replica.fetch.wait.max.ms 默认值:500

复制数据过程中,为了fetch数据,replica发送请求给leader的最大的等待时间。

replica.fetch.min.bytes 默认值:1

复制数据过程中,replica收到的每个fetch响应,期望的最小的字节数,如果没有收到足够的字节数,就会等待期望更多的数据,直到达到replica.fetch.wait.max.ms。

num.replica.fetchers 默认值:1

用来从leader复制消息的线程数量,增大这个值可以增加follow的I/O并行度。

replica.high.watermark.checkpoint.interval.ms 默认值:5000

每一个replica存储自己的high watermark到磁盘的频率,用来日后的recovery。

fetch.purgatory.purge.interval.requests 默认值:10000

含义暂不明,日后研究。The purge interval (in number of requests) of the fetch request purgatory.

producer.purgatory.purge.interval.requests 默认值:10000

含义暂不明,日后研究。The purge interval (in number of requests) of the producer request purgatory.

zookeeper.session.timeout.ms 默认值:6000

ZooKeeper的session的超时时间,如果在这段时间内没有收到ZK的心跳,则会被认为该Kafka server挂掉了。如果把这个值设置得过低可能被误认为挂掉,如果设置得过高,如果真的挂了,则需要很长时间才能被server得知。

zookeeper.connection.timeout.ms 默认值:6000

client连接到ZK server的超时时间。

zookeeper.sync.time.ms 默认值:2000

一个ZK follower能落后leader多久。

controlled.shutdown.enable 默认值:false

如果为true,在关闭一个broker前,会把当前broker上的所有partition,如果有为leader的话,会把leader权交给其他broker上的相应的partition。这会降低在关闭期间不可用的时间窗口。

controlled.shutdown.max.retries 默认值:3

在执行一个unclean(强行关闭?)的关闭操作前,为了成功完成关闭操作,最大的重试次数。

controlled.shutdown.retry.backoff.ms 默认值:5000

在关闭重试期间的回退(backoff)时间。

auto.leader.rebalance.enable 默认值:false

如果设为true,复制控制器会周期性的自动尝试,为所有的broker的每个partition平衡leadership,为更优先(preferred)的replica分配leadership。

leader.imbalance.per.broker.percentage 默认值:10

每个broker允许的不平衡的leader的百分比。如果每个broker超过了这个百分比,复制控制器会重新平衡leadership。

leader.imbalance.check.interval.seconds 默认值:300

检测leader不平衡的时间间隔。

offset.metadata.max.bytes 默认值:1024

允许client(消费者)保存它们元数据(offset)的最大的数据量。

 

kafka producer配置

  1. #指定kafka节点列表,用于获取metadata,不必全部指定
  2. metadata.broker.list=192.168.2.105:9092,192.168.2.106:9092
  3. # 指定分区处理类。默认kafka.producer.DefaultPartitioner,表通过key哈希到对应分区
  4. #partitioner.class=com.meituan.mafka.client.producer.CustomizePartitioner
  5. # 是否压缩,默认0表示不压缩,1表示用gzip压缩,2表示用snappy压缩。压缩后消息中会有头来指明消息压缩类型,故在消费者端消息解压是透明的无需指定。
  6. compression.codec=none
  7. # 指定序列化处理类(mafka client API调用说明-->3.序列化约定wiki),默认为kafka.serializer.DefaultEncoder,即byte[]
  8. serializer.class=com.meituan.mafka.client.codec.MafkaMessageEncoder
  9. # serializer.class=kafka.serializer.DefaultEncoder
  10. # serializer.class=kafka.serializer.StringEncoder
  11. # 如果要压缩消息,这里指定哪些topic要压缩消息,默认empty,表示不压缩。
  12. #compressed.topics=
  13. ########### request ack ###############
  14. # producer接收消息ack的时机.默认为0.
  15. # 0: producer不会等待broker发送ack
  16. # 1: 当leader接收到消息之后发送ack
  17. # 2: 当所有的follower都同步消息成功后发送ack.
  18. request.required.acks=0
  19. # 在向producer发送ack之前,broker允许等待的最大时间
  20. # 如果超时,broker将会向producer发送一个error ACK.意味着上一次消息因为某种
  21. # 原因未能成功(比如follower未能同步成功)
  22. request.timeout.ms=10000
  23. ########## end #####################
  24. # 同步还是异步发送消息,默认“sync”表同步,"async"表异步。异步可以提高发送吞吐量,
  25. # 也意味着消息将会在本地buffer中,并适时批量发送,但是也可能导致丢失未发送过去的消息
  26. producer.type=sync
  27. ############## 异步发送 (以下四个异步参数可选) ####################
  28. # 在async模式下,当message被缓存的时间超过此值后,将会批量发送给broker,默认为5000ms
  29. # 此值和batch.num.messages协同工作.
  30. queue.buffering.max.ms = 5000
  31. # 在async模式下,producer端允许buffer的最大消息量
  32. # 无论如何,producer都无法尽快的将消息发送给broker,从而导致消息在producer端大量沉积
  33. # 此时,如果消息的条数达到阀值,将会导致producer端阻塞或者消息被抛弃,默认为10000
  34. queue.buffering.max.messages=20000
  35. # 如果是异步,指定每次批量发送数据量,默认为200
  36. batch.num.messages=500
  37. # 当消息在producer端沉积的条数达到"queue.buffering.max.meesages"后
  38. # 阻塞一定时间后,队列仍然没有enqueue(producer仍然没有发送出任何消息)
  39. # 此时producer可以继续阻塞或者将消息抛弃,此timeout值用于控制"阻塞"的时间
  40. # -1: 无阻塞超时限制,消息不会被抛弃
  41. # 0:立即清空队列,消息被抛弃
  42. queue.enqueue.timeout.ms=-1
  43. ################ end ###############
  44. # 当producer接收到error ACK,或者没有接收到ACK时,允许消息重发的次数
  45. # 因为broker并没有完整的机制来避免消息重复,所以当网络异常时(比如ACK丢失)
  46. # 有可能导致broker接收到重复的消息,默认值为3.
  47. message.send.max.retries=3
  48. # producer刷新topic metada的时间间隔,producer需要知道partition leader的位置,以及当前topic的情况
  49. # 因此producer需要一个机制来获取最新的metadata,当producer遇到特定错误时,将会立即刷新
  50. # (比如topic失效,partition丢失,leader失效等),此外也可以通过此参数来配置额外的刷新机制,默认值600000
  51. topic.metadata.refresh.interval.ms=60000

kafkaconsumer端配置

    1. # zookeeper连接服务器地址,此处为线下测试环境配置(kafka消息服务-->kafka broker集群线上部署环境wiki)
    2. # 配置例子:"127.0.0.1:3000,127.0.0.1:3001,127.0.0.1:3002"
    3. zookeeper.connect=192.168.2.225:2181,192.168.2.225:2182,192.168.2.225:2183/config/mobile/mq/mafka
    4. # zookeeper的session过期时间,默认5000ms,用于检测消费者是否挂掉,当消费者挂掉,其他消费者要等该指定时间才能检查到并且触发重新负载均衡
    5. zookeeper.session.timeout.ms=5000
    6. zookeeper.connection.timeout.ms=10000
    7. # 指定多久消费者更新offset到zookeeper中。注意offset更新时基于time而不是每次获得的消息。一旦在更新zookeeper发生异常并重启,将可能拿到已拿到过的消息
    8. zookeeper.sync.time.ms=2000
    9. #指定消费组
    10. group.id=xxx
    11. # 当consumer消费一定量的消息之后,将会自动向zookeeper提交offset信息
    12. # 注意offset信息并不是每消费一次消息就向zk提交一次,而是现在本地保存(内存),并定期提交,默认为true
    13. auto.commit.enable=true
    14. # 自动更新时间。默认60 * 1000
    15. auto.commit.interval.ms=1000
    16. # 当前consumer的标识,可以设定,也可以有系统生成,主要用来跟踪消息消费情况,便于观察
    17. conusmer.id=xxx
    18. # 消费者客户端编号,用于区分不同客户端,默认客户端程序自动产生
    19. client.id=xxxx
    20. # 最大取多少块缓存到消费者(默认10)
    21. queued.max.message.chunks=50
    22. # 当有新的consumer加入到group时,将会reblance,此后将会有partitions的消费端迁移到新
    23. # 的consumer上,如果一个consumer获得了某个partition的消费权限,那么它将会向zk注册
    24. # "Partition Owner registry"节点信息,但是有可能此时旧的consumer尚没有释放此节点,
    25. # 此值用于控制,注册节点的重试次数.
    26. rebalance.max.retries=5
    27. # 获取消息的最大尺寸,broker不会像consumer输出大于此值的消息chunk
    28. # 每次feth将得到多条消息,此值为总大小,提升此值,将会消耗更多的consumer端内存
    29. fetch.min.bytes=6553600
    30. # 当消息的尺寸不足时,server阻塞的时间,如果超时,消息将立即发送给consumer
    31. fetch.wait.max.ms=5000
    32. socket.receive.buffer.bytes=655360
    33. # 如果zookeeper没有offset值或offset值超出范围。那么就给个初始的offset。有smallest、largest、
    34. # anything可选,分别表示给当前最小的offset、当前最大的offset、抛异常。默认largest
    35. auto.offset.reset=smallest
    36. # 指定序列化处理类(mafka client API调用说明-->3.序列化约定wiki),默认为kafka.serializer.DefaultDecoder,即byte[]
    37. derializer.class=com.meituan.mafka.client.codec.MafkaMessageDecoder

kafka 配置文件注释的更多相关文章

  1. Ibatis XML 配置文件注释引起错误及解决方案

    详见:http://blog.yemou.net/article/query/info/tytfjhfascvhzxcytp35 Ibatis XML 配置文件注释引起错误及解决方案 最近在使用Iba ...

  2. Hadoop生态圈-Kafka配置文件详解

    Hadoop生态圈-Kafka配置文件详解 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.默认kafka配置文件内容([yinzhengjie@s101 ~]$ more /s ...

  3. kafka配置文件中参数的限制

    在kafka的优化过程中,不断的调节配置文件中的参数,但是有时候会遇到java.lang.NumberFormatException这样的错误 比如socket.receive.buffer.byte ...

  4. caffe-windows之网络描述文件和参数配置文件注释(mnist例程)

    caffe-windows之网络描述文件和参数配置文件注释(mnist例程) lenet_solver.prototxt:在训练和测试时涉及到一些参数配置,训练超参数文件 <-----lenet ...

  5. kafka实战教程(python操作kafka),kafka配置文件详解

    kafka实战教程(python操作kafka),kafka配置文件详解 应用往Kafka写数据的原因有很多:用户行为分析.日志存储.异步通信等.多样化的使用场景带来了多样化的需求:消息是否能丢失?是 ...

  6. Kafka配置文件server.properties(三个版本)

    前言 其实每个版本都有些许改动,只不过改动大小而已,但是网上的教程都真的太老了,其实更新一下也费不了多少时间 0.9.0 # Licensed to the Apache Software Found ...

  7. MySQL数据库my.cnf配置文件注释详解

    我们知道,在MySQL数据库安装完成后,要对my.cnf配置文件进行适当的修改才能充分利用MySQL数据库的功能.但是对于初学者来说,修改my.cnf配置文件似乎是一个比较难的过程.为了解决这个问题, ...

  8. MySQL my.cnf 配置文件注释

    以下是my.cnf配置文件参数解释 [client] port                     = 3309socket                   = /home/longxiben ...

  9. 《转》vue-cli的webpack模板项目配置文件注释

    一.文件结构 本文主要分析开发(dev)和构建(build)两个过程涉及到的文件,故下面文件结构仅列出相应的内容. ├─build │ ├─build.js │ ├─check-versions.js ...

随机推荐

  1. NIO SelectionKey attachment()空指针错误

    Channel注册到Selector时添加了一个Object: serverSocketChannel1.register(selector, SelectionKey.OP_ACCEPT, num[ ...

  2. css布局 三栏 自动换行

    1.代码实现 <!DOCTYPE html> <html lang="zh"> <head> <meta charset="UT ...

  3. JAVA中的CountDownLatch、CyclicBarrier、Semaphore的简单测试

    因公司需要做一个对于CountDownLatch的分享,特写了此blog. 具体细节可以参见:小结java自带的跟锁相关的一些类 在做这个分享的过程中发现了Main和junit的运行的区别,在另外一个 ...

  4. jQuery方法区别(四)click() bind() live() delegate()区别

        click(),bind(),live()都是执行事件时使用的方法,他们之前是有一些区别的,我们在使用这些方法时应该根据需要进行选择. 1.click()方法是我们经常使用的单击事件方法: $ ...

  5. PHP中json_encode中文编码的问题_学习

    /** * 由于php的json扩展自带的函数json_encode会将汉字转换成unicode码 * 所以我们在这里用自定义的json_encode,这个函数不会将汉字转换为unicode码 */ ...

  6. Mac Mini 2011 mid 安装Ubuntu18.06.1 Server

    在Mac mini上原来是安装的ESXi5.5, 时间比较久了, 因为内存只有8g, 跑不了几个vm, 逐渐闲置. 现在打算重新装一个Ubuntu Sever用来跑docker. 制作启动U盘 参考  ...

  7. Node.js的一些基本概念

    1. Node.js简介 1.1 Node.js是什么 简单的说 Node.js 就是运行在服务端的 JavaScript. Node.js是一个能够在服务器端运行JavaScript的开放源代码.跨 ...

  8. (原)luarocks install 提示 failed fetching manifest

    转载请注明出处: http://www.cnblogs.com/darkknightzh/p/6400169.html 参考网址: https://github.com/torch/torch7/is ...

  9. Spring3.0.3使用之异常解决

    2010-10-29  温馨提示:         以下异常仅在Spring3.0.3版本中遇到,其他版本可能也会遇到,读者可作参考.不保证会顺利通过.         近期在学习Spring3的一些 ...

  10. numpy中的argpartition

    numpy.argpartition(a, kth, axis=-1, kind='introselect', order=None) 在快排算法中,有一个典型的操作:partition.这个操作指: ...