Kafka配置说明

 

Broker  Configs

 

 

Property	Default	Description
broker.id		每一个broker均可以用一个惟一的非负整数id进行标识；这个id能够做为broker的“名字”，而且它的存在使得broker无须混淆consumers就能够迁移到不一样的host/port上。你能够选择任意你喜欢的数字做为id，只要id是惟一的便可。
log.dirs	/tmp/kafka-logs	kafka存放数据的路径。这个路径并非惟一的，能够是多个，路径之间只须要使用逗号分隔便可；每当建立新partition时，都会选择在包含最少partitions的路径下进行。
port	6667	server接受客户端链接的端口
zookeeper.connect	null	ZooKeeper链接字符串的格式为：hostname:port，此处hostname和port分别是ZooKeeper集群中某个节点的host和port；为了当某个host宕掉以后你能经过其余ZooKeeper节点进行链接，你能够按照一下方式制定多个hosts： hostname1:port1, hostname2:port2, hostname3:port3. ZooKeeper 容许你增长一个“chroot”路径，将集群中全部kafka数据存放在特定的路径下。当多个Kafka集群或者其余应用使用相同ZooKeeper集群时，可使用这个方式设置数据存放路径。这种方式的实现能够经过这样设置链接字符串格式，以下所示： hostname1：port1，hostname2：port2，hostname3：port3/chroot/path 这样设置就将全部kafka集群数据存放在/chroot/path路径下。注意，在你启动broker以前，你必须建立这个路径，而且consumers必须使用相同的链接格式。
message.max.bytes	1000000	server能够接收的消息最大尺寸。重要的是，consumer和producer有关这个属性的设置必须同步，不然producer发布的消息对consumer来讲太大。
num.network.threads	3	server用来处理网络请求的网络线程数目；通常你不须要更改这个属性。
num.io.threads	8	server用来处理请求的I/O线程的数目；这个线程数目至少要等于硬盘的个数。
background.threads	4	用于后台处理的线程数目，例如文件删除；你不须要更改这个属性。
queued.max.requests	500	在网络线程中止读取新请求以前，能够排队等待I/O线程处理的最大请求个数。
host.name	null	broker的hostname；若是hostname已经设置的话，broker将只会绑定到这个地址上；若是没有设置，它将绑定到全部接口，并发布一份到ZK
advertised.host.name	null	若是设置，则就做为broker 的hostname发往producer、consumers以及其余brokers
advertised.port	null	此端口将给与producers、consumers、以及其余brokers，它会在创建链接时用到； 它仅在实际端口和server须要绑定的端口不同时才须要设置。
socket.send.buffer.bytes	100 * 1024	SO_SNDBUFF 缓存大小，server进行socket 链接所用
socket.receive.buffer.bytes	100 * 1024	SO_RCVBUFF缓存大小，server进行socket链接时所用
socket.request.max.bytes	100 * 1024 * 1024	server容许的最大请求尺寸；  这将避免server溢出，它应该小于Java  heap size
num.partitions	1	若是建立topic时没有给出划分partitions个数，这个数字将是topic下partitions数目的默认数值。
log.segment.bytes	1014*1024*1024	topic  partition的日志存放在某个目录下诸多文件中，这些文件将partition的日志切分红一段一段的；这个属性就是每一个文件的最大尺寸；当尺寸达到这个数值时，就会建立新文件。此设置能够由每一个topic基础设置时进行覆盖。 查看  the per-topic  configuration section
log.roll.hours	24 * 7	即便文件没有到达log.segment.bytes，只要文件建立时间到达此属性，就会建立新文件。这个设置也能够有topic层面的设置进行覆盖； 查看the per-topic  configuration section
log.cleanup.policy	delete
log.retention.minutes和log.retention.hours	7 days	每一个日志文件删除以前保存的时间。默认数据保存时间对全部topic都同样。 log.retention.minutes 和 log.retention.bytes 都是用来设置删除日志文件的，不管哪一个属性已经溢出。 这个属性设置能够在topic基本设置时进行覆盖。 查看the per-topic  configuration section
log.retention.bytes	-1	每一个topic下每一个partition保存数据的总量；注意，这是每一个partitions的上限，所以这个数值乘以partitions的个数就是每一个topic保存的数据总量。同时注意：若是log.retention.hours和log.retention.bytes都设置了，则超过了任何一个限制都会形成删除一个段文件。 注意，这项设置能够由每一个topic设置时进行覆盖。 查看the per-topic  configuration section
log.retention.check.interval.ms	5 minutes	检查日志分段文件的间隔时间，以肯定是否文件属性是否到达删除要求。
log.cleaner.enable	false	当这个属性设置为false时，一旦日志的保存时间或者大小达到上限时，就会被删除；若是设置为true，则当保存属性达到上限时，就会进行log compaction。
log.cleaner.threads	1	进行日志压缩的线程数
log.cleaner.io.max.bytes.per.second	None	进行log compaction时，log cleaner能够拥有的最大I/O数目。这项设置限制了cleaner，以免干扰活动的请求服务。
log.cleaner.io.buffer.size	500*1024*1024	log cleaner清除过程当中针对日志进行索引化以及精简化所用到的缓存大小。最好设置大点，以提供充足的内存。
log.cleaner.io.buffer.load.factor	512*1024	进行log cleaning时所须要的I/O chunk尺寸。你不须要更改这项设置。
log.cleaner.io.buffer.load.factor	0.9	log cleaning中所使用的hash表的负载因子；你不须要更改这个选项。
log.cleaner.backoff.ms	15000	进行日志是否清理检查的时间间隔
log.cleaner.min.cleanable.ratio	0.5	这项配置控制log  compactor试图清理日志的频率（假定log compaction是打开的）。默认避免清理压缩超过50%的日志。这个比率绑定了备份日志所消耗的最大空间（50%的日志备份时压缩率为50%）。更高的比率则意味着浪费消耗更少，也就能够更有效的清理更多的空间。这项设置在每一个topic设置中能够覆盖。 查看the per-topic  configuration section。
log.cleaner.delete.retention.ms	1day	保存时间；保存压缩日志的最长时间；也是客户端消费消息的最长时间，荣log.retention.minutes的区别在于一个控制未压缩数据，一个控制压缩后的数据；会被topic建立时的指定时间覆盖。
log.index.size.max.bytes	10*1024*1024	每一个log segment的最大尺寸。注意，若是log尺寸达到这个数值，即便尺寸没有超过log.segment.bytes限制，也须要产生新的log  segment。
log.index.interval.bytes	4096	当执行一次fetch后，须要必定的空间扫描最近的offset，设置的越大越好，通常使用默认值就能够
log.flush.interval.messages	Long.MaxValue	log文件“sync”到磁盘以前累积的消息条数。由于磁盘IO操做是一个慢操做，但又是一个“数据可靠性”的必要手段，因此检查是否须要固化到硬盘的时间间隔。须要在“数据可靠性”与“性能”之间作必要的权衡，若是此值过大，将会致使每次“发sync”的时间过长（IO阻塞），若是此值太小，将会致使“fsync”的时间较长（IO阻塞），若是此值太小，将会致使”发sync“的次数较多，这也就意味着总体的client请求有必定的延迟，物理server故障，将会致使没有fsync的消息丢失。
log.flush.scheduler.interval.ms	Long.MaxValue	检查是否须要fsync的时间间隔
log.flush.interval.ms	Long.MaxValue	仅仅经过interval来控制消息的磁盘写入时机，是不足的，这个数用来控制”fsync“的时间间隔，若是消息量始终没有达到固化到磁盘的消息数，可是离上次磁盘同步的时间间隔达到阈值，也将触发磁盘同步。
log.delete.delay.ms	60000	文件在索引中清除后的保留时间，通常不须要修改
auto.create.topics.enable	true	是否容许自动建立topic。若是是真的，则produce或者fetch 不存在的topic时，会自动建立这个topic。不然须要使用命令行建立topic
controller.socket.timeout.ms	30000	partition管理控制器进行备份时，socket的超时时间。
controller.message.queue.size	Int.MaxValue	controller-to-broker-channles的buffer 尺寸
default.replication.factor	1	默认备份份数，仅指自动建立的topics
replica.lag.time.max.ms	10000	若是一个follower在这个时间内没有发送fetch请求，leader将从ISR重移除这个follower，并认为这个follower已经挂了
replica.lag.max.messages	4000	若是一个replica没有备份的条数超过这个数值，则leader将移除这个follower，并认为这个follower已经挂了
replica.socket.timeout.ms	30*1000	leader 备份数据时的socket网络请求的超时时间
replica.socket.receive.buffer.bytes	64*1024	备份时向leader发送网络请求时的socket receive buffer
replica.fetch.max.bytes	1024*1024	备份时每次fetch的最大值
replica.fetch.min.bytes	500	leader发出备份请求时，数据到达leader的最长等待时间
replica.fetch.min.bytes	1	备份时每次fetch以后回应的最小尺寸
num.replica.fetchers	1	从leader备份数据的线程数
replica.high.watermark.checkpoint.interval.ms	5000	每一个replica检查是否将最高水位进行固化的频率
fetch.purgatory.purge.interval.requests	1000	fetch 请求清除时的清除间隔
producer.purgatory.purge.interval.requests	1000	producer请求清除时的清除间隔
zookeeper.session.timeout.ms	6000	zookeeper会话超时时间。
zookeeper.connection.timeout.ms	6000	客户端等待和zookeeper创建链接的最大时间
zookeeper.sync.time.ms	2000	zk follower落后于zk leader的最长时间
controlled.shutdown.enable	true	是否可以控制broker的关闭。若是可以，broker将能够移动全部leaders到其余的broker上，在关闭以前。这减小了不可用性在关机过程当中。
controlled.shutdown.max.retries	3	在执行不完全的关机以前，能够成功执行关机的命令数。
controlled.shutdown.retry.backoff.ms	5000	在关机之间的backoff时间
auto.leader.rebalance.enable	true	若是这是true，控制者将会自动平衡brokers对于partitions的leadership
leader.imbalance.per.broker.percentage	10	每一个broker所容许的leader最大不平衡比率
leader.imbalance.check.interval.seconds	300	检查leader不平衡的频率
offset.metadata.max.bytes	4096	容许客户端保存他们offsets的最大个数
max.connections.per.ip	Int.MaxValue	每一个ip地址上每一个broker能够被链接的最大数目
max.connections.per.ip.overrides		每一个ip或者hostname默认的链接的最大覆盖
connections.max.idle.ms	600000	空链接的超时限制
log.roll.jitter.{ms,hours}	0	从logRollTimeMillis抽离的jitter最大数目
num.recovery.threads.per.data.dir	1	每一个数据目录用来日志恢复的线程数目
unclean.leader.election.enable	true	指明了是否可以使不在ISR中replicas设置用来做为leader
delete.topic.enable	false	可以删除topic
offsets.topic.num.partitions	50	The number of partitions for the offset commit topic. Since changing this after deployment is currently unsupported, we recommend using a higher setting for production (e.g., 100-200).
offsets.topic.retention.minutes	1440	存在时间超过这个时间限制的offsets都将被标记为待删除
offsets.retention.check.interval.ms	600000	offset管理器检查陈旧offsets的频率
offsets.topic.replication.factor	3	topic的offset的备份份数。建议设置更高的数字保证更高的可用性
offset.topic.segment.bytes	104857600	offsets topic的segment尺寸。
offsets.load.buffer.size	5242880	这项设置与批量尺寸相关，当从offsets segment中读取时使用。
offsets.commit.required.acks	-1	在offset  commit能够接受以前，须要设置确认的数目，通常不须要更改

 

 

 

 

 

Property	Default	Server Default Property	Description
cleanup.policy	delete	log.cleanup.policy	要么是”delete“要么是”compact“； 这个字符串指明了针对旧日志部分的利用方式；默认方式（"delete"）将会丢弃旧的部分当他们的回收时间或者尺寸限制到达时。”compact“将会进行日志压缩
delete.retention.ms	86400000 (24 hours)	log.cleaner.delete.retention.ms	对于压缩日志保留的最长时间，也是客户端消费消息的最长时间，通log.retention.minutes的区别在于一个控制未压缩数据，一个控制压缩后的数据。此项配置能够在topic建立时的置顶参数覆盖
flush.messages	None	log.flush.interval.messages	此项配置指定时间间隔：强制进行fsync日志。例如，若是这个选项设置为1，那么每条消息以后都须要进行fsync，若是设置为5，则每5条消息就须要进行一次fsync。通常来讲，建议你不要设置这个值。此参数的设置,须要在"数据可靠性"与"性能"之间作必要的权衡.若是此值过大,将会致使每次"fsync"的时间较长(IO阻塞),若是此值太小,将会致使"fsync"的次数较多,这也意味着总体的client请求有必定的延迟.物理server故障,将会致使没有fsync的消息丢失.
flush.ms	None	log.flush.interval.ms	此项配置用来置顶强制进行fsync日志到磁盘的时间间隔；例如，若是设置为1000，那么每1000ms就须要进行一次fsync。通常不建议使用这个选项
index.interval.bytes	4096	log.index.interval.bytes	默认设置保证了咱们每4096个字节就对消息添加一个索引，更多的索引使得阅读的消息更加靠近，可是索引规模却会由此增大；通常不须要改变这个选项
max.message.bytes	1000000	max.message.bytes	kafka追加消息的最大尺寸。注意若是你增大这个尺寸，你也必须增大你consumer的fetch 尺寸，这样consumer才能fetch到这些最大尺寸的消息。
min.cleanable.dirty.ratio	0.5	min.cleanable.dirty.ratio	此项配置控制log压缩器试图进行清除日志的频率。默认状况下，将避免清除压缩率超过50%的日志。这个比率避免了最大的空间浪费
min.insync.replicas	1	min.insync.replicas	当producer设置request.required.acks为-1时，min.insync.replicas指定replicas的最小数目（必须确认每个repica的写数据都是成功的），若是这个数目没有达到，producer会产生异常。
retention.bytes	None	log.retention.bytes	若是使用“delete”的retention  策略，这项配置就是指在删除日志以前，日志所能达到的最大尺寸。默认状况下，没有尺寸限制而只有时间限制
retention.ms	7 days	log.retention.ms	若是使用“delete”的retention策略，这项配置就是指删除日志前日志保存的时间。
segment.bytes	1GB	log.segment.bytes	kafka中log日志是分红一块块存储的，此配置是指log日志划分红块的大小
segment.index.bytes	10MB	log.index.size.max.bytes	此配置是有关offsets和文件位置之间映射的索引文件的大小；通常不须要修改这个配置
segment.ms	7 days	log.roll.hours	即便log的分块文件没有达到须要删除、压缩的大小，一旦log 的时间达到这个上限，就会强制新建一个log分块文件
segment.jitter.ms	0	log.roll.jitter.{ms,hours}	The maximum jitter to subtract from logRollTimeMillis.

 

 

 

 

 

Consumer  Configs

 

 

Property	Default	Description
group.id		用来惟一标识consumer进程所在组的字符串，若是设置一样的group  id，表示这些processes都是属于同一个consumer  group
zookeeper.connect		指定zookeeper的链接的字符串，格式是hostname：port，此处host和port都是zookeeper server的host和port，为避免某个zookeeper 机器宕机以后失联，你能够指定多个hostname：port，使用逗号做为分隔： hostname1：port1，hostname2：port2，hostname3：port3 能够在zookeeper链接字符串中加入zookeeper的chroot路径，此路径用于存放他本身的数据，方式： hostname1：port1，hostname2：port2，hostname3：port3/chroot/path
consumer.id	null	不须要设置，通常自动产生
socket.timeout.ms	30*100	网络请求的超时限制。真实的超时限制是   max.fetch.wait+socket.timeout.ms
socket.receive.buffer.bytes	64*1024	socket用于接收网络请求的缓存大小
fetch.message.max.bytes	1024*1024	每次fetch请求中，针对每次fetch消息的最大字节数。这些字节将会督导用于每一个partition的内存中，所以，此设置将会控制consumer所使用的memory大小。这个fetch请求尺寸必须至少和server容许的最大消息尺寸相等，不然，producer可能发送的消息尺寸大于consumer所能消耗的尺寸。
num.consumer.fetchers	1	用于fetch数据的fetcher线程数
auto.commit.enable	true	若是为真，consumer所fetch的消息的offset将会自动的同步到zookeeper。这项提交的offset将在进程挂掉时，由新的consumer使用
auto.commit.interval.ms	60*1000	consumer向zookeeper提交offset的频率，单位是秒
queued.max.message.chunks	2	用于缓存消息的最大数目，以供consumption。每一个chunk必须和fetch.message.max.bytes相同
rebalance.max.retries	4	当新的consumer加入到consumer  group时，consumers集合试图从新平衡分配到每一个consumer的partitions数目。若是consumers集合改变了，当分配正在执行时，这个从新平衡会失败并重入
fetch.min.bytes	1	每次fetch请求时，server应该返回的最小字节数。若是没有足够的数据返回，请求会等待，直到足够的数据才会返回。
fetch.wait.max.ms	100	若是没有足够的数据可以知足fetch.min.bytes，则此项配置是指在应答fetch请求以前，server会阻塞的最大时间。
rebalance.backoff.ms	2000	在重试reblance以前backoff时间
refresh.leader.backoff.ms	200	在试图肯定某个partition的leader是否失去他的leader地位以前，须要等待的backoff时间
auto.offset.reset	largest	zookeeper中没有初始化的offset时，若是offset是如下值的回应： smallest：自动复位offset为smallest的offset largest：自动复位offset为largest的offset anything  else：向consumer抛出异常
consumer.timeout.ms	-1	若是没有消息可用，即便等待特定的时间以后也没有，则抛出超时异常
exclude.internal.topics	true	是否将内部topics的消息暴露给consumer
paritition.assignment.strategy	range	选择向consumer 流分配partitions的策略，可选值：range，roundrobin
client.id	group id value	是用户特定的字符串，用来在每次请求中帮助跟踪调用。它应该能够逻辑上确认产生这个请求的应用
zookeeper.session.timeout.ms	6000	zookeeper 会话的超时限制。若是consumer在这段时间内没有向zookeeper发送心跳信息，则它会被认为挂掉了，而且reblance将会产生
zookeeper.connection.timeout.ms	6000	客户端在创建通zookeeper链接中的最大等待时间
zookeeper.sync.time.ms	2000	ZK follower能够落后ZK leader的最大时间
offsets.storage	zookeeper	用于存放offsets的地点： zookeeper或者kafka
offset.channel.backoff.ms	1000	从新链接offsets channel或者是重试失败的offset的fetch/commit请求的backoff时间
offsets.channel.socket.timeout.ms	10000	当读取offset的fetch/commit请求回应的socket 超时限制。此超时限制是被consumerMetadata请求用来请求offset管理
offsets.commit.max.retries	5	重试offset commit的次数。这个重试只应用于offset  commits在shut-down之间。他
dual.commit.enabled	true	若是使用“kafka”做为offsets.storage，你能够二次提交offset到zookeeper(还有一次是提交到kafka）。在zookeeper-based的offset  storage到kafka-based的offset storage迁移时，这是必须的。对任意给定的consumer  group来讲，比较安全的建议是当完成迁移以后就关闭这个选项
partition.assignment.strategy	range	在“range”和“roundrobin”策略之间选择一种做为分配partitions给consumer 数据流的策略； 循环的partition分配器分配全部可用的partitions以及全部可用consumer  线程。它会将partition循环的分配到consumer线程上。若是全部consumer实例的订阅都是肯定的，则partitions的划分是肯定的分布。循环分配策略只有在如下条件知足时才能够：（1）每一个topic在每一个consumer实力上都有一样数量的数据流。（2）订阅的topic的集合对于consumer  group中每一个consumer实例来讲都是肯定的。

 

Producer  Configs

 

 

Property	Default	Description
metadata.broker.list		服务于bootstrapping。producer仅用来获取metadata（topics，partitions，replicas）。发送实际数据的socket链接将基于返回的metadata数据信息而创建。格式是： host1：port1，host2：port2 这个列表能够是brokers的子列表或者是一个指向brokers的VIP
request.required.acks	0	此配置是代表当一次produce请求被认为完成时的确认值。特别是，多少个其余brokers必须已经提交了数据到他们的log而且向他们的leader确认了这些信息。典型的值包括： 0： 表示producer历来不等待来自broker的确认信息（和0.7同样的行为）。这个选择提供了最小的时延但同时风险最大（由于当server宕机时，数据将会丢失）。 1：表示得到leader replica已经接收了数据的确认信息。这个选择时延较小同时确保了server确认接收成功。 -1：producer会得到全部同步replicas都收到数据的确认。同时时延最大，然而，这种方式并无彻底消除丢失消息的风险，由于同步replicas的数量多是1.若是你想确保某些replicas接收到数据，那么你应该在topic-level设置中选项min.insync.replicas设置一下。请阅读一下设计文档，能够得到更深刻的讨论。
request.timeout.ms	10000	broker尽力实现request.required.acks需求时的等待时间，不然会发送错误到客户端
producer.type	sync	此选项置顶了消息是否在后台线程中异步发送。正确的值： （1）  async： 异步发送 （2）  sync： 同步发送 经过将producer设置为异步，咱们能够批量处理请求（有利于提升吞吐率）可是这也就形成了客户端机器丢掉未发送数据的可能性
serializer.class	kafka.serializer.DefaultEncoder	消息的序列化类别。默认编码器输入一个字节byte[]，而后返回相同的字节byte[]
key.serializer.class		关键字的序列化类。若是没给与这项，默认状况是和消息一致
partitioner.class	kafka.producer.DefaultPartitioner	partitioner 类，用于在subtopics之间划分消息。默认partitioner基于key的hash表
compression.codec	none	此项参数能够设置压缩数据的codec，可选codec为：“none”， “gzip”， “snappy”
compressed.topics	null	此项参数能够设置某些特定的topics是否进行压缩。若是压缩codec是NoCompressCodec以外的codec，则对指定的topics数据应用这些codec。若是压缩topics列表是空，则将特定的压缩codec应用于全部topics。若是压缩的codec是NoCompressionCodec，压缩对全部topics军不可用。
message.send.max.retries	3	此项参数将使producer自动重试失败的发送请求。此项参数将置顶重试的次数。注意：设定非0值将致使重复某些网络错误：引发一条发送并引发确认丢失
retry.backoff.ms	100	在每次重试以前，producer会更新相关topic的metadata，以此进行查看新的leader是否分配好了。由于leader的选择须要一点时间，此选项指定更新metadata以前producer须要等待的时间。
topic.metadata.refresh.interval.ms	600*1000	producer通常会在某些失败的状况下（partition missing，leader不可用等）更新topic的metadata。他将会规律的循环。若是你设置为负值，metadata只有在失败的状况下才更新。若是设置为0，metadata会在每次消息发送后就会更新（不建议这种选择，系统消耗太大）。重要提示： 更新是有在消息发送后才会发生，所以，若是producer历来不发送消息，则metadata历来也不会更新。
queue.buffering.max.ms	5000	当应用async模式时，用户缓存数据的最大时间间隔。例如，设置为100时，将会批量处理100ms以内消息。这将改善吞吐率，可是会增长因为缓存产生的延迟。
queue.buffering.max.messages	10000	当使用async模式时，在在producer必须被阻塞或者数据必须丢失以前，能够缓存到队列中的未发送的最大消息条数
batch.num.messages	200	使用async模式时，能够批量处理消息的最大条数。或者消息数目已到达这个上线或者是queue.buffer.max.ms到达，producer才会处理
send.buffer.bytes	100*1024	socket 写缓存尺寸
client.id	“”	这个client  id是用户特定的字符串，在每次请求中包含用来追踪调用，他应该逻辑上能够确认是那个应用发出了这个请求。

 

 

 

Producer  Configs

 

 

Name	Type	Default	Importance	Description
boostrap.servers	list		high	用于创建与kafka集群链接的host/port组。数据将会在全部servers上均衡加载，无论哪些server是指定用于bootstrapping。这个列表仅仅影响初始化的hosts（用于发现所有的servers）。这个列表格式： host1:port1,host2:port2,... 由于这些server仅仅是用于初始化的链接，以发现集群全部成员关系（可能会动态的变化），这个列表不须要包含全部的servers（你可能想要不止一个server，尽管这样，可能某个server宕机了）。若是没有server在这个列表出现，则发送数据会一直失败，直到列表可用。
acks	string	1	high	producer须要server接收到数据以后发出的确认接收的信号，此项配置就是指procuder须要多少个这样的确认信号。此配置实际上表明了数据备份的可用性。如下设置为经常使用选项： （1）acks=0： 设置为0表示producer不须要等待任何确认收到的信息。副本将当即加到socket  buffer并认为已经发送。没有任何保障能够保证此种状况下server已经成功接收数据，同时重试配置不会发生做用（由于客户端不知道是否失败）回馈的offset会老是设置为-1； （2）acks=1： 这意味着至少要等待leader已经成功将数据写入本地log，可是并无等待全部follower是否成功写入。这种状况下，若是follower没有成功备份数据，而此时leader又挂掉，则消息会丢失。 （3）acks=all： 这意味着leader须要等待全部备份都成功写入日志，这种策略会保证只要有一个备份存活就不会丢失数据。这是最强的保证。 （4）其余的设置，例如acks=2也是能够的，这将须要给定的acks数量，可是这种策略通常不多用。
buffer.memory	long	33554432	high	producer能够用来缓存数据的内存大小。若是数据产生速度大于向broker发送的速度，producer会阻塞或者抛出异常，以“block.on.buffer.full”来代表。 这项设置将和producer可以使用的总内存相关，但并非一个硬性的限制，由于不是producer使用的全部内存都是用于缓存。一些额外的内存会用于压缩（若是引入压缩机制），一样还有一些用于维护请求。
compression.type	string	none	high	producer用于压缩数据的压缩类型。默认是无压缩。正确的选项值是none、gzip、snappy。 压缩最好用于批量处理，批量处理消息越多，压缩性能越好。
retries	int	0	high	设置大于0的值将使客户端从新发送任何数据，一旦这些数据发送失败。注意，这些重试与客户端接收到发送错误时的重试没有什么不一样。容许重试将潜在的改变数据的顺序，若是这两个消息记录都是发送到同一个partition，则第一个消息失败第二个发送成功，则第二条消息会比第一条消息出现要早。
batch.size	int	16384	medium	producer将试图批处理消息记录，以减小请求次数。这将改善client与server之间的性能。这项配置控制默认的批量处理消息字节数。 不会试图处理大于这个字节数的消息字节数。 发送到brokers的请求将包含多个批量处理，其中会包含对每一个partition的一个请求。 较小的批量处理数值比较少用，而且可能下降吞吐量（0则会仅用批量处理）。较大的批量处理数值将会浪费更多内存空间，这样就须要分配特定批量处理数值的内存大小。
client.id	string		medium	当向server发出请求时，这个字符串会发送给server。目的是可以追踪请求源头，以此来容许ip/port许可列表以外的一些应用能够发送信息。这项应用能够设置任意字符串，由于没有任何功能性的目的，除了记录和跟踪
linger.ms	long	0	medium	producer组将会汇总任何在请求与发送之间到达的消息记录一个单独批量的请求。一般来讲，这只有在记录产生速度大于发送速度的时候才能发生。然而，在某些条件下，客户端将但愿下降请求的数量，甚至下降到中等负载一下。这项设置将经过增长小的延迟来完成--即，不是当即发送一条记录，producer将会等待给定的延迟时间以容许其余消息记录发送，这些消息记录能够批量处理。这能够认为是TCP种Nagle的算法相似。这项设置设定了批量处理的更高的延迟边界：一旦咱们得到某个partition的batch.size，他将会当即发送而不顾这项设置，然而若是咱们得到消息字节数比这项设置要小的多，咱们须要“linger”特定的时间以获取更多的消息。 这个设置默认为0，即没有延迟。设定linger.ms=5，例如，将会减小请求数目，可是同时会增长5ms的延迟。
max.request.size	int	1028576	medium	请求的最大字节数。这也是对最大记录尺寸的有效覆盖。注意：server具备本身对消息记录尺寸的覆盖，这些尺寸和这个设置不一样。此项设置将会限制producer每次批量发送请求的数目，以防发出巨量的请求。
receive.buffer.bytes	int	32768	medium	TCP receive缓存大小，当阅读数据时使用
send.buffer.bytes	int	131072	medium	TCP send缓存大小，当发送数据时使用
timeout.ms	int	30000	medium	此配置选项控制server等待来自followers的确认的最大时间。若是确认的请求数目在此时间内没有实现，则会返回一个错误。这个超时限制是以server端度量的，没有包含请求的网络延迟
block.on.buffer.full	boolean	true	low	当咱们内存缓存用尽时，必须中止接收新消息记录或者抛出错误。默认状况下，这个设置为真，然而某些阻塞可能不值得期待，所以当即抛出错误更好。设置为false则会这样：producer会抛出一个异常错误：BufferExhaustedException， 若是记录已经发送同时缓存已满
metadata.fetch.timeout.ms	long	60000	low	是指咱们所获取的一些元素据的第一个时间数据。元素据包含：topic，host，partitions。此项配置是指当等待元素据fetch成功完成所须要的时间，不然会跑出异常给客户端。
metadata.max.age.ms	long	300000	low	以微秒为单位的时间，是在咱们强制更新metadata的时间间隔。即便咱们没有看到任何partition leadership改变。
metric.reporters	list	[]	low	类的列表，用于衡量指标。实现MetricReporter接口，将容许增长一些类，这些类在新的衡量指标产生时就会改变。JmxReporter总会包含用于注册JMX统计
metrics.num.samples	int	2	low	用于维护metrics的样本数
metrics.sample.window.ms	long	30000	low	metrics系统维护可配置的样本数量，在一个可修正的window  size。这项配置配置了窗口大小，例如。咱们可能在30s的期间维护两个样本。当一个窗口推出后，咱们会擦除并重写最老的窗口
recoonect.backoff.ms	long	10	low	链接失败时，当咱们从新链接时的等待时间。这避免了客户端反复重连
retry.backoff.ms	long	100	low	在试图重试失败的produce请求以前的等待时间。避免陷入发送-失败的死循环中。