Property

Default

Description

broker.id

每个 broker都可以用一个唯一的非负整数 id 进行标识；这个 id 可以作为 broker 的“名字”，并且它的存在使得 broker 无须混淆 consumers 就可以迁移到不同的 host/port 上。你可以选择任意你喜欢的数字作为 id，只要 id 是唯一的即可。

log.dirs

/tmp/kafka-logs

kafka存放数据的路径。这个路径并不是唯一的，

可以是多个，路径之间只需要使用逗号分隔即

可；每当创建新 partition 时，都会选择在包含最少 partitions 的路径下进行。

port

9092

server 接受客户端连接的端口

zookeeper.connect

localhost:2181

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 基础设置时进行覆盖。

查看 theper-topic   configurationsection

log.roll.hours

24 * 7

即使文件没有到达 log.segment.bytes，只要

文件创建时间到达此属性，就会创建新文件。这个设置也可以有 topic 层面的设置进行覆盖；查看 theper-topicconfigurationsection

log.cleanup.policy

delete

log.retention.minutes 和 log.retention.hours

7 days

每个日志文件删除之前保存的时间。默认数据保存时间对所有 topic 都一样。

log.retention.minutes 和

log.retention.bytes 都是用来设置删除日志文件的，无论哪个属性已经溢出。

这个属性设置可以在 topic 基本设置时进行覆盖。

查看 theper-topic  configurationsection

log.retention.bytes

-1

每个 topic 下每个 partition 保存数据的总量；注意，这是每个 partitions 的上限，因此这个数值乘以 partitions的个数就是每个 topic保存的

数据总量。同时注意：如果 log.retention.hours 和 log.retention.bytes 都设置了，则超过了任何一个限制都会造成删除一个段文件。

注意，这项设置可以由每个 topic 设置时进行覆盖。

查看 theper-topic  configurationsection

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试图清理日志的频率（假定 logcompaction是打开的）。默认避免清理压缩超过 50%的日志。这个比率绑定了备份日志所消耗的最大空间（50%的日志备份时压缩率为 50%）。更高的比率则意味着浪费消耗更少，也就可以更有效的清理更多的空间。

这项设置在每个 topic 设置中可以覆盖。

查看 theper-topic  configurationsection。

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.minutes

如果使用“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.

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 实例来说都是确定的。

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.messag

es

10000

当使用
async 模式时，在在 producer 必须被阻塞或者数据必须丢失之前，可以缓存到队列中的未发送的最大消息条数

batch.num.messages

200

使用 async
模式时，可以批量处理消息的最大条数。或者消息数目已到达这个上线或者

是
queue.buffer.max.ms 到达，producer 才会处理

send.buffer.bytes

100*1024

socket
写缓存尺寸

client.id

“”

这个
client id 是用户特定的字符串，在每次请求中包含用来追踪调用，他应该逻辑上可以确认是那个应用发出了这个请求。

Name

Type

Default

Importance

Description

bootstrap.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 总会包含用