2. API

卡夫卡包括五个核心API：

该生产 API允许应用程序发送数据流的卡夫卡集群中的主题。
该消费者 API允许应用程序从卡夫卡集群中的主题读取数据流。
该流 API允许将来自输入主题数据流输出的主题。
所述连接 API允许实现连接器，其连续地从一些源系统或应用拉进卡夫卡或从卡夫卡推入一些水槽系统或应用程序。
该的AdminClient API允许管理和检查课题，经纪人和其他卡夫卡对象。

Kafka通过独立于语言的协议公开了所有功能，客户端可以使用许多编程语言。但是，只有Java客户端是作为主要Kafka项目的一部分进行维护的，其他的则作为独立的开源项目提供。非Java客户的名单可在这里。

2.1生产者API

Producer API允许应用程序将数据流发送到Kafka集群中的主题。

信息内数信亦范范范辛中中内数信息中信息

要使用生产者，你可以使用下面的maven依赖：

五

<groupId>org.apache.kafka</groupId>

<artifactId>kafka-clients</artifactId>

</dependency>

2.2消费者API

Consumer API允许应用程序从Kafka集群中的主题读取数据流。

展示如何使用消费者的例子在javadoc中给出。

要使用使用者，你可以使用下面的maven依赖：

五

<groupId>org.apache.kafka</groupId>

<artifactId>kafka-clients</artifactId>

</dependency>

2.3流API

该流 API允许将来自输入主题数据流输出的主题。

展示如何使用这个库的例子在javadoc中给出

有关使用Streams API的其他文档可以在这里找到。

要使用Kafka Streams，您可以使用以下maven依赖项：

五

<groupId>org.apache.kafka</groupId>

<artifactId>kafka-streams</artifactId>

</dependency>

2.4连接API

Connect API允许实现不断从一些源数据系统中拉入Kafka的连接器，或者从Kafka推入一些接收器数据系统。

Connect的许多用户不需要直接使用这个API，但是他们可以使用预先建立的连接器而不需要编写任何代码。有关使用Connect的更多信息，请点击这里。

那些想要实现自定义连接器的人可以看到javadoc。

2.5 AdminClient API

AdminClient API支持管理和检查主题，代理，acl和其他Kafka对象。

要使用AdminClient API，请添加以下Maven依赖项：

五

<groupId>org.apache.kafka</groupId>

<artifactId>kafka-clients</artifactId>

</dependency>

有关AdminClient API的更多信息，请参阅javadoc。

2.6传统的API

卡夫卡还包括一个更有限的传统生产者和消费者API。这些旧的Scala API已被弃用，只能用于兼容目的。关于他们的信息可以在这里找到。

3.配置

Kafka使用属性文件格式的键值对进行配置。这些值可以从文件或编程方式提供。

3.1经纪人配置

基本配置如下：

broker.id
log.dirs
zookeeper.connect

下面将更详细地讨论主题级别的配置和默认设置。

名称	描述	类型	默认	有效值	重要性
zookeeper.connect	Zookeeper主机字符串	串			高
advertised.host.name	DEPRECATED：仅在未设置“advertised.listeners”或“listeners”时使用。改用`advertised.listeners`。主机名发布到ZooKeeper供客户使用。在IaaS环境中，这可能需要与代理绑定的接口不同。如果未设置，则将使用“host.name”的值（如果已配置）。否则，它将使用从java.net.InetAddress.getCanonicalHostName（）返回的值。	串	空值		高
advertised.listeners	监听器发布到ZooKeeper供客户端使用，如果不同于`listeners`配置属性。在IaaS环境中，这可能需要与代理绑定的接口不同。如果没有设置，将使用`listeners`的值。与“监听者”不同，发布0.0.0.0元地址是无效的。	串	空值		高
advertised.port	DEPRECATED：仅在未设置“advertised.listeners”或“listeners”时使用。改用`advertised.listeners`。发布到ZooKeeper供客户端使用的端口。在IaaS环境中，这可能需要与代理绑定的端口不同。如果没有设置，它将发布代理绑定到的相同端口。	INT	空值		高
auto.create.topics.enable	在服务器上启用自动创建主题	布尔	真正		高
auto.leader.rebalance.enable	启用自动领导者平衡。后台线程会定期检查并触发领导平衡	布尔	真正		高
background.threads	用于各种后台处理任务的线程数	INT	10	[1，...]	高
broker.id	此服务器的代理ID。如果未设置，则会生成唯一的代理标识。为避免zookeeper生成的代理标识与用户配置的代理标识之间的冲突，生成的代理标识从reserved.broker.max.id + 1开始。	INT	-1		高
compression.type	指定给定主题的最终压缩类型。此配置接受标准压缩编解码器（'gzip'，'snappy'，'lz4'）。它另外接受相当于不压缩的“未压缩” 和“制作者”，这意味着保留制作者设置的原始压缩编解码器。	串	制片人		高
delete.topic.enable	启用删除主题。如果此配置已关闭，则通过管理工具删除主题将不起作用	布尔	真正		高
主机名	DEPRECATED：仅在未设置“侦听器”时使用。使用`listeners`来代替。经纪人的主机名。如果这个设置，它只会绑定到这个地址。如果没有设置，它将绑定到所有接口	串	“”		高
leader.imbalance.check.interval.seconds	分区重新平衡检查的频率由控制器触发	长	300		高
leader.imbalance.per.broker.percentage	每个经纪人允许的领导者不平衡比率。如果每个经纪人的价值高于这个值，控制器会触发一个领导者的平衡。该值以百分比形式指定。	INT	10		高
听众	监听器列表 - 逗号分隔的我们将监听的URI列表和监听器名称。如果侦听器名称不是安全协议，则还必须设置listener.security.protocol.map。指定主机名为0.0.0.0以绑定到所有接口。保留主机名为空以绑定到默认界面。合法侦听器列表的示例：PLAINTEXT：// myhost：9092，SSL：//：9091 CLIENT：//0.0.0.0：9092，REPLICATION：// localhost：9093	串	空值		高
log.dir	保存日志数据的目录（对log.dirs属性的补充）	串	的/ tmp /卡夫卡-日志		高
log.dirs	日志数据保存的目录。如果未设置，则使用log.dir中的值	串	空值		高
log.flush.interval.messages	在将消息刷新到磁盘之前，在日志分区上累积的消息数量	长	9223372036854775807	[1，...]	高
log.flush.interval.ms	任何主题中的消息在刷新到磁盘之前都保留在内存中的最长时间（以毫秒为单位）。如果未设置，则使用log.flush.scheduler.interval.ms中的值	长	空值		高
log.flush.offset.checkpoint.interval.ms	我们更新作为日志恢复点的最后一次刷新的持久记录的频率	INT	60000	[0，...]	高
log.flush.scheduler.interval.ms	日志刷新器检查是否需要将任何日志刷新到磁盘的频率（以毫秒为单位）	长	9223372036854775807		高
log.flush.start.offset.checkpoint.interval.ms	我们更新记录起始偏移量的持续记录的频率	INT	60000	[0，...]	高
log.retention.bytes	删除之前日志的最大大小	长	-1		高
log.retention.hours	保留日志文件的小时数（以小时为单位），大写为log.retention.ms属性	INT	168		高
log.retention.minutes	在删除日志文件之前保留日志的分钟数（以分钟为单位），次要log.retention.ms属性。如果未设置，则使用log.retention.hours中的值	INT	空值		高
log.retention.ms	保留日志文件的毫秒数（以毫秒为单位），如果未设置，则使用log.retention.minutes中的值	长	空值		高
log.roll.hours	新日志段推出之前的最长时间（小时），次于log.roll.ms属性	INT	168	[1，...]	高
log.roll.jitter.hours	从logRollTimeMillis减去的最大抖动（以小时为单位），次要log.roll.jitter.ms属性	INT	0	[0，...]	高
log.roll.jitter.ms	从logRollTimeMillis中减去的最大抖动（以毫秒为单位）。如果未设置，则使用log.roll.jitter.hours中的值	长	空值		高
log.roll.ms	新日志段转出之前的最长时间（以毫秒为单位）。如果未设置，则使用log.roll.hours中的值	长	空值		高
log.segment.bytes	单个日志文件的最大大小	INT	1073741824	[14，...]	高
log.segment.delete.delay.ms	从文件系统中删除文件之前等待的时间	长	60000	[0，...]	高
message.max.bytes	卡夫卡允许的最大记录批量大小。如果这个数字增加，并且有超过0.10.2的消费者，那么消费者的提取大小也必须增加，以便他们可以取得这么大的记录批次。在最新的消息格式版本中，记录总是分组分批以提高效率。在以前的消息格式版本中，未压缩的记录不会分组到批次中，并且此限制仅适用于该情况下的单个记录。这可以使用主题级别max.message.bytes配置为每个主题设置。	INT	1000012	[0，...]	高
min.insync.replicas	当生产者将ack设置为“全部”（或“-1”）时，min.insync.replicas指定必须确认写入被认为成功的最小副本数。如果这个最小值不能满足，那么生产者将会引发一个异常（NotEnoughReplicas或NotEnoughReplicasAfterAppend）。当一起使用时，min.insync.replicas和acks允许您执行更大的耐久性保证。一个典型的情况是创建一个复制因子为3的主题，将min.insync.replicas设置为2，并使用“全部”选项来产生。这将确保生产者如果大多数副本没有收到写入引发异常。	INT	1	[1，...]	高
num.io.threads	服务器用于处理请求的线程数，可能包括磁盘I / O	INT	8	[1，...]	高
num.network.threads	服务器用于接收来自网络的请求并向网络发送响应的线程数	INT	3	[1，...]	高
num.recovery.threads.per.data.dir	每个数据目录的线程数，用于启动时的日志恢复和关闭时的刷新	INT	1	[1，...]	高
num.replica.fetchers	用于从源代理复制消息的读取器线程数。增加此值可以提高跟随者代理中的I / O并行度。	INT	1		高
offset.metadata.max.bytes	与偏移量提交相关联的元数据条目的最大大小	INT	4096		高
offsets.commit.required.acks	提交之前所需的确认可以被接受。一般来说，默认值（-1）不应该被覆盖	短	-1		高
offsets.commit.timeout.ms	偏移提交将被延迟，直到偏移量主题的所有副本都收到提交或达到此超时。这与生产者请求超时类似。	INT	5000	[1，...]	高
offsets.load.buffer.size	将偏移量加载到缓存中时从批量偏移段读取的批量大小。	INT	5242880	[1，...]	高
offsets.retention.check.interval.ms	检查失效偏移的频率	长	600000	[1，...]	高
offsets.retention.minutes	比这个保留期更早的偏置将被丢弃	INT	1440	[1，...]	高
offsets.topic.compression.codec	用于偏移主题的压缩编解码器 - 压缩可用于实现“原子”提交	INT	0		高
offsets.topic.num.partitions	偏移提交主题的分区数量（部署后不应更改）	INT	50	[1，...]	高
offsets.topic.replication.factor	偏移量主题的复制因子（设置得更高以确保可用性）。内部主题创建将失败，直到群集大小满足此复制因子要求。	短	3	[1，...]	高
offsets.topic.segment.bytes	为了便于更快的日志压缩和缓存加载，偏移量的主题段字节应保持相对较小	INT	104857600	[1，...]	高
港口	DEPRECATED：仅在未设置“侦听器”时使用。使用`listeners`来代替。端口监听和接受连接	INT	9092		高
queued.max.requests	阻塞网络线程之前允许排队的请求数量	INT	500	[1，...]	高
quota.consumer.default	DEPRECATED：仅在未配置动态默认配额时使用要么在Zookeeper中。如果clientId / consumer组区分的每个客户端获取的字节数多于此值，那么任何使用者都将被限制	长	9223372036854775807	[1，...]	高
quota.producer.default	DEPRECATED：仅在未配置动态默认配额时使用，要么在Zookeeper中。如果产生的字节数大于每秒钟的这个值，任何由clientId区分的生产者都将受到限制	长	9223372036854775807	[1，...]	高
replica.fetch.min.bytes	每个提取响应的预期最小字节数。如果没有足够的字节，请等待replicaMaxWaitTimeMs	INT	1		高
replica.fetch.wait.max.ms	跟随者副本发出的每个获取请求的最长等待时间。此值始终应始终小于replica.lag.time.max.ms，以防止针对低吞吐量主题频繁收缩ISR	INT	500		高
replica.high.watermark.checkpoint.interval.ms	高水印被保存到磁盘的频率	长	5000		高
replica.lag.time.max.ms	如果一个追随者至少没有发送任何提取请求，或者至少在这段时间内没有消耗掉领导者的日志偏移量，那么领导者会从isr	长	10000		高
replica.socket.receive.buffer.bytes	套接字接收缓冲区的网络请求	INT	65536		高
replica.socket.timeout.ms	网络请求的套接字超时。它的值应该至少是replica.fetch.wait.max.ms	INT	30000		高
request.timeout.ms	配置控制客户端等待请求响应的最长时间。如果在超时过去之前未收到响应，则客户端将在必要时重新发送请求，或者如果重试耗尽，则请求失败。	INT	30000		高
socket.receive.buffer.bytes	套接字服务器插槽的SO_RCVBUF缓冲区。如果值为-1，则将使用操作系统默认值。	INT	102400		高
socket.request.max.bytes	套接字请求中的最大字节数	INT	104857600	[1，...]	高
socket.send.buffer.bytes	套接字服务器套接字的SO_SNDBUF缓冲区。如果值为-1，则将使用操作系统默认值。	INT	102400		高
transaction.max.timeout.ms	交易的最大允许超时时间。如果客户请求的交易时间超过这个时间，那么代理将在InitProducerIdRequest中返回一个错误。这样可以防止客户过度超时，从而阻碍消费者阅读交易中包含的主题。	INT	900000	[1，...]	高
transaction.state.log.load.buffer.size	将生产者ID和事务加载到缓存中时，从事务日志段读取的批量大小。	INT	5242880	[1，...]	高
transaction.state.log.min.isr	覆盖事务主题的min.insync.replicas配置。	INT	2	[1，...]	高
transaction.state.log.num.partitions	事务主题的分区数量（部署后不应更改）。	INT	50	[1，...]	高
transaction.state.log.replication.factor	交易主题的复制因子（设置更高以确保可用性）。内部主题创建将失败，直到群集大小满足此复制因子要求。	短	3	[1，...]	高
transaction.state.log.segment.bytes	事务主题段字节应保持相对较小，以便于更快的日志压缩和缓存负载	INT	104857600	[1，...]	高
transactional.id.expiration.ms	事务协调器在未收到任何事务状态更新之前主动过期生产者的事务标识之前将等待的最长时间（以毫秒为单位）。	INT	604800000	[1，...]	高
unclean.leader.election.enable	指示是否启用不在ISR集合中的副本作为最后的选择，尽管这样做可能导致数据丢失	布尔	假		高
zookeeper.connection.timeout.ms	客户端等待与zookeeper建立连接的最长时间。如果未设置，则使用zookeeper.session.timeout.ms中的值	INT	空值		高
zookeeper.session.timeout.ms	Zookeeper会话超时	INT	6000		高
zookeeper.set.acl	将客户端设置为使用安全ACL	布尔	假		高
broker.id.generation.enable	在服务器上启用自动代理ID生成。启用时，应该检查为reserved.broker.max.id配置的值。	布尔	真正		中
broker.rack	经纪人的机架。这将在机架感知复制分配中用于容错。例如：`RACK1`，`us-east-1d`	串	空值		中
connections.max.idle.ms	空闲连接超时：服务器套接字处理器线程关闭闲置超过此的连接	长	600000		中
controlled.shutdown.enable	启用服务器的受控关闭	布尔	真正		中
controlled.shutdown.max.retries	受控关机可能由于多种原因而失败。这决定了发生这种故障时的重试次数	INT	3		中
controlled.shutdown.retry.backoff.ms	在每次重试之前，系统需要时间从导致先前故障的状态（控制器故障切换，副本延迟等）中恢复。此配置确定重试之前等待的时间量。	长	5000		中
controller.socket.timeout.ms	控制器到代理通道的套接字超时	INT	30000		中
default.replication.factor	自动创建主题的默认复制因子	INT	1		中
delete.records.purgatory.purge.interval.requests	删除记录请求purge的清除间隔（请求数）	INT	1		中
fetch.purgatory.purge.interval.requests	提取请求purge的清除间隔（请求数）	INT	1000		中
group.initial.rebalance.delay.ms	在执行第一次再平衡之前，团队协调员将等待更多消费者加入新团队的时间。延迟时间越长意味着重新平衡的可能性越小，但是直到处理开始的时间增加。	INT	3000		中
group.max.session.timeout.ms	注册用户的最大允许会话超时。较长的超时使消费者有更多的时间来处理心跳之间的消息，代价是检测失败的时间更长。	INT	300000		中
group.min.session.timeout.ms	注册用户允许的最小会话超时。更短的超时导致以更频繁的消费者心跳为代价的更快速的故障检测，这可能压倒经纪人资源。	INT	6000		中
inter.broker.listener.name	用于经纪人之间沟通的听众名称。如果未设置，则侦听器名称由security.inter.broker.protocol定义。同时设置此和security.inter.broker.protocol属性是错误的。	串	空值		中
inter.broker.protocol.version	指定将使用哪个版本的代理间协议。在所有经纪人升级到新版本之后，这通常会受到冲击。一些有效值的示例如下：0.8.0，0.8.1，0.8.1.1，0.8.2，0.8.2.0，0.8.2.1，0.9.0.0，0.9.0.1检查ApiVersion的完整列表。	串	1.0- IV0		中
log.cleaner.backoff.ms	没有日志清理的时间	长	15000	[0，...]	中
log.cleaner.dedupe.buffer.size	用于所有清理程序线程的日志重复数据消除的总内存	长	134217728		中
log.cleaner.delete.retention.ms	删除记录保留多久？	长	86400000		中
log.cleaner.enable	启用日志清理器进程在服务器上运行。应该启用，如果使用cleanup.policy = compact任何主题，包括内部偏移主题。如果被禁用的话，这些话题将不会被压缩，并且会不断增长。	布尔	真正		中
log.cleaner.io.buffer.load.factor	日志清理器重复数据删除缓存负载因完全重复数据删除缓冲区的百分比可以变成。更高的值将允许一次清理更多的日志，但会导致更多的散列冲突	双	0.9		中
log.cleaner.io.buffer.size	用于日志清理程序I / O缓冲区的整个内存跨越所有清理程序线程	INT	524288	[0，...]	中
log.cleaner.io.max.bytes.per.second	日志清理器将受到限制，所以其读取和写入I / O的总和将平均小于此值	双	1.7976931348623157E308		中
log.cleaner.min.cleanable.ratio	日志中的脏日志与总日志的最小比率，以符合清理的条件	双	0.5		中
log.cleaner.min.compaction.lag.ms	消息在日志中保持未压缩的最短时间。仅适用于正在压缩的日志。	长	0		中
log.cleaner.threads	用于日志清理的后台线程数量	INT	1	[0，...]	中
log.cleanup.policy	超出保留窗口的段的默认清理策略。以逗号分隔的有效策略列表。有效的政策是：“删除”和“紧凑”	名单	删除	[精简，删除]	中
log.index.interval.bytes	我们添加一个条目到偏移索引的时间间隔	INT	4096	[0，...]	中
log.index.size.max.bytes	偏移索引的最大大小（以字节为单位）	INT	10485760	[4，...]	中
log.message.format.version	指定代理将用于将消息附加到日志的消息格式版本。该值应该是有效的ApiVersion。一些例子是：0.8.2，0.9.0.0，0.10.0，查看ApiVersion获取更多细节。通过设置特定的消息格式版本，用户正在证明磁盘上的所有现有消息小于或等于指定的版本。不正确地设置这个值将导致使用旧版本的用户中断，因为他们将接收到他们不理解的格式的消息。	串	1.0- IV0		中
log.message.timestamp.difference.max.ms	代理收到消息时的时间戳和消息中指定的时间戳之间允许的最大差异。如果log.message.timestamp.type = CreateTime，如果时间戳的差值超过此阈值，则会拒绝一条消息。如果log.message.timestamp.type = LogAppendTime，则忽略此配置。允许的最大时间戳差异不应大于log.retention.ms，以避免不必要地频繁进行日志滚动。	长	9223372036854775807		中
log.message.timestamp.type	定义消息中的时间戳是消息创建时间还是日志追加时间。该值应该是“CreateTime”或“LogAppendTime”	串	CreateTime	[CreateTime，LogAppendTime]	中
log.preallocate	创建新分段时应该预先分配文件吗？如果您在Windows上使用Kafka，则可能需要将其设置为true。	布尔	假		中
log.retention.check.interval.ms	日志清理程序检查是否有日志符合删除的频率（以毫秒为单位）	长	300000	[1，...]	中
max.connections.per.ip	我们从每个IP地址允许的最大连接数	INT	2147483647	[1，...]	中
max.connections.per.ip.overrides	每个IP或主机名将覆盖默认的最大连接数	串	“”		中
num.partitions	每个主题的默认日志分区数量	INT	1	[1，...]	中
principal.builder.class	实现KafkaPrincipalBuilder接口的类的完全限定名，用于构建在授权过程中使用的KafkaPrincipal对象。此配置还支持以前用于通过SSL进行客户端身份验证的弃用的PrincipalBuilder接口。如果未定义主体构建器，则默认行为取决于正在使用的安全协议。对于SSL身份验证，如果提供了一个主体名称，则主体名称将是客户端证书的可分辨名称; 否则，如果客户端身份验证不是必需的，主体名称将是匿名的。对于SASL身份验证，将使用sasl.kerberos.principal.to.local.rulesif GSSAPI正在使用中定义的规则以及其他机制的SASL身份验证ID 导出主体。对于PLAINTEXT，校长将是匿名的。	类	空值		中
producer.purgatory.purge.interval.requests	生产者请求炼狱的清除间隔（请求数）	INT	1000		中
queued.max.request.bytes	在不再读取请求之前，允许排队的字节数	长	-1		中
replica.fetch.backoff.ms	提取分区错误时发生的睡眠时间。	INT	1000	[0，...]	中
replica.fetch.max.bytes	尝试为每个分区获取的消息的字节数。这不是绝对最大值，如果第一个非空分区中的第一个记录批次大于此值，那么记录批次仍将被返回以确保可以进行。代理接受的最大记录批量大小通过message.max.bytes（代理配置）或max.message.bytes（主题配置）进行定义。	INT	1048576	[0，...]	中
replica.fetch.response.max.bytes	整个提取响应的预期最大字节数。记录是批量提取的，如果第一个记录批次在第一个非空分区的分区大于这个值，那么记录批次仍然会被返回，以确保可以进行。因此，这不是一个绝对的最大值。代理接受的最大记录批量大小通过message.max.bytes（代理配置）或max.message.bytes（主题配置）进行定义。	INT	10485760	[0，...]	中
reserved.broker.max.id	可以用于broker.id的最大数量	INT	1000	[0，...]	中
sasl.enabled.mechanisms	卡夫卡服务器中启用的SASL机制列表。该列表可能包含安全提供程序可用的任何机制。只有GSSAPI默认启用。	名单	GSSAPI		中
sasl.kerberos.kinit.cmd	Kerberos kinit命令路径。	串	在/ usr / bin中/ kinit命令		中
sasl.kerberos.min.time.before.relogin	登录线程在刷新尝试之间的休眠时间	长	60000		中
sasl.kerberos.principal.to.local.rules	从主体名称到简称（通常是操作系统用户名）的映射规则列表。规则按顺序进行评估，并使用匹配主体名称的第一条规则将其映射到短名称。列表中后面的任何规则都会被忽略。默认情况下，{username} / {hostname} @ {REALM}形式的主体名称映射到{username}。有关格式的更多细节，请参阅安全授权和acls。请注意，如果principal.builder.class配置提供了KafkaPrincipalBuilder的扩展，则忽略此配置。	名单	默认		中
sasl.kerberos.service.name	Kafka运行的Kerberos主体名称。这可以在Kafka的JAAS配置或Kafka的配置中定义。	串	空值		中
sasl.kerberos.ticket.renew.jitter	随机抖动增加到更新时间的百分比。	双	0.05		中
sasl.kerberos.ticket.renew.window.factor	登录线程将休眠，直到已经到达从上次刷新到票证到期的指定窗口时间因子，届时它将尝试更新票证。	双	0.8		中
sasl.mechanism.inter.broker.protocol	用于经纪人间通信的SASL机制。默认是GSSAPI。	串	GSSAPI		中
security.inter.broker.protocol	用于在代理之间进行通信的安全协议。有效值为：PLAINTEXT，SSL，SASL_PLAINTEXT，SASL_SSL。同时设置此属性和inter.broker.listener.name属性是错误的。	串	纯文本		中
ssl.cipher.suites	密码套件列表。这是用于使用TLS或SSL网络协议来协商网络连接的安全设置的认证，加密，MAC和密钥交换算法的命名组合。默认情况下，所有可用的密码套件都受支持。	名单	空值		中
ssl.client.auth	配置kafka代理来请求客户端认证。以下设置是常见的： ssl.client.auth=required 如果设置为需要客户端身份验证是必需的 ssl.client.auth=requested这意味着客户端认证是可选的。不像请求，如果这个选项被设置，客户端可以选择不提供关于它自己的认证信息 ssl.client.auth=none 这意味着不需要客户端身份验证。	串	没有	[必填，请求，无]	中
ssl.enabled.protocols	启用了SSL连接的协议列表。	名单	TLSv1.2工作，TLSv1.1，使用TLSv1		中
ssl.key.password	密钥存储文件中的私钥密码。这对于客户端是可选的。	密码	空值		中
ssl.keymanager.algorithm	密钥管理器工厂用于SSL连接的算法。信息范范范读预辛辛	串	SunX509		中
ssl.keystore.location	密钥存储文件的位置。这对客户端是可选的，可以用于客户端的双向认证。	串	空值		中
ssl.keystore.password	密钥存储文件的商店密码。这对客户端是可选的，只有在配置了ssl.keystore.location时才需要。	密码	空值		中
ssl.keystore.type	密钥存储文件的文件格式。这对于客户端是可选的。	串	JKS		中
ssl.protocol	用于生成SSLContext的SSL协议。默认设置是TLS，在大多数情况下这是很好的。最近的JVM中允许的值是TLS，TLSv1.1和TLSv1.2。较旧的JVM中可能支持SSL，SSLv2和SSLv3，但由于已知的安全漏洞，它们的使用不受欢迎。	串	TLS		中
ssl.provider	用于SSL连接的安全提供程序的名称。默认值是JVM的默认安全提供程序。	串	空值		中
ssl.trustmanager.algorithm	信任管理器工厂用于SSL连接的算法。默认值是为Java虚拟机配置的信任管理器工厂算法。	串	PKIX		中
ssl.truststore.location	信任存储文件的位置。	串	空值		中
ssl.truststore.password	信任存储文件的密码。如果密码未设置，信任库的访问仍然可用，但完整性检查被禁用。	密码	空值		中
ssl.truststore.type	信任存储文件的文件格式。	串	JKS		中
alter.config.policy.class.name	应该用于验证的alter configs策略类。该类应该实现org.apache.kafka.server.policy.AlterConfigPolicy接口。	类	空值		低
authorizer.class.name	应该用于授权的授权者类	串	“”		低
create.topic.policy.class.name	应该用于验证的创建主题策略类。该类应该实现org.apache.kafka.server.policy.CreateTopicPolicy接口。	类	空值		低
listener.security.protocol.map	侦听器名称和安全协议之间的映射。必须定义相同的安全协议才能在多个端口或IP中使用。例如，即使两者都需要SSL，内部和外部流量也可以分开。具体来说，用户可以定义名字为INTERNAL和EXTERNAL的监听器，这个属性为：`INTERNAL：SSL，EXTERNAL：SSL`。如图所示，键和值由冒号分隔，映射条目以逗号分隔。每个侦听器名称只能在地图中出现一次。通过向配置名称添加标准化前缀（侦听器名称小写），可以为每个侦听器配置不同的安全性（SSL和SASL）设置。例如，要为INTERNAL侦听器设置不同的密钥库，将会设置名称为“listener.name.internal.ssl.keystore.location”的配置。	串	PLAINTEXT：明文SSL：SSL，SASL_PLAINTEXT：SASL_PLAINTEXT，SASL_SSL：SASL_SSL		低
metric.reporters	用作度量记录的类的列表。实现org.apache.kafka.common.metrics.MetricsReporter接口允许插入将被通知新度量创建的类。JmxReporter始终包含在注册JMX统计信息中。	名单	“”		低
metrics.num.samples	维持用于计算度量的样本数量。	INT	2	[1，...]	低
metrics.recording.level	指标的最高记录级别。	串	信息		低
metrics.sample.window.ms	计算指标样本的时间窗口。	长	30000	[1，...]	低
quota.window.num	为客户配额保留的内存样本数	INT	11	[1，...]	低
quota.window.size.seconds	客户配额的每个样本的时间跨度	INT	1	[1，...]	低
replication.quota.window.num	要保留在内存中用于复制配额的样本数	INT	11	[1，...]	低
replication.quota.window.size.seconds	每个样本复制配额的时间跨度	INT	1	[1，...]	低
ssl.endpoint.identification.algorithm	使用服务器证书验证服务器主机名的端点识别算法。	串	空值		低
ssl.secure.random.implementation	用于SSL加密操作的SecureRandom PRNG实现。	串	空值		低
transaction.abort.timed.out.transaction.cleanup.interval.ms	回滚已超时的事务的时间间隔	INT	60000	[1，...]	低
transaction.remove.expired.transaction.cleanup.interval.ms	因删除已到期的交易的时间间隔transactional.id.expiration.ms passing	INT	3600000	[1，...]	低
zookeeper.sync.time.ms	ZK追随者可以在ZK领导者后面走多远	INT	2000		低

有关代理配置的更多细节可以在scala类中找到kafka.server.KafkaConfig。

3.2主题级别的配置

与主题相关的配置既包含服务器默认值，也包含可选的每个主题覆盖值。如果没有给出每个主题的配置，则使用服务器默认值。可以通过给定一个或多个--config选项来在主题创建时设置覆盖。本示例使用自定义的最大消息大小和冲刷率创建一个名为my-topic的主题：

1 2	> bin/kafka-topics.sh --zookeeper localhost:2181 --create --topic my-topic --partitions 1 --replication-factor 1 --config max.message.bytes=64000 --config flush.messages=1

也可以使用alter configs命令稍后更改或设置覆盖。本示例更新my-topic的最大邮件大小：

1 2	> bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name my-topic --alter --add-config max.message.bytes=128000

要检查在主题上设置的覆盖，您可以执行

1	> bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name my-topic --describe

要删除覆盖，你可以做

1	> bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name my-topic --alter --delete-config max.message.bytes

以下是主题级配置。该属性的服务器默认配置在“服务器默认属性”标题下给出。给定的服务器默认配置值只适用于主题，如果它没有明确的主题配置覆盖。

名称	描述	类型	默认	有效值	服务器默认属性	重要性
cleanup.policy	一个字符串，可以是“delete”或“compact”。此字符串指定在旧日志段上使用的保留策略。默认策略（“删除”）将在达到保留时间或大小限制时丢弃旧段。“紧凑”设置将启用该主题的日志压缩。	名单	删除	[精简，删除]	log.cleanup.policy	中
compression.type	指定给定主题的最终压缩类型。这个配置接受标准的压缩编解码器（'gzip'，'snappy'，lz4）。它另外接受相当于不压缩的“未压缩” 和“制作者”，这意味着保留制作者设置的原始压缩编解码器。	串	制片人	[uncompressed，snappy，lz4，gzip，制作人]	compression.type	中
delete.retention.ms	保留时间删除逻辑压缩主题的逻辑删除标记。这个设置也给消费者在从偏移量0开始时必须完成读取的时间以确保他们获得最后阶段的有效快照（否则删除在他们完成扫描之前可以收集的墓碑）。	长	86400000	[0，...]	log.cleaner.delete.retention.ms	中
file.delete.delay.ms	The time to wait before deleting a file from the filesystem	long	60000	[0,...]	log.segment.delete.delay.ms	medium
flush.messages	This setting allows specifying an interval at which we will force an fsync of data written to the log. For example if this was set to 1 we would fsync after every message; if it were 5 we would fsync after every five messages. In general we recommend you not set this and use replication for durability and allow the operating system's background flush capabilities as it is more efficient. This setting can be overridden on a per-topic basis (see the per-topic configuration section).	long	9223372036854775807	[0,...]	log.flush.interval.messages	medium
flush.ms	This setting allows specifying a time interval at which we will force an fsync of data written to the log. For example if this was set to 1000 we would fsync after 1000 ms had passed. In general we recommend you not set this and use replication for durability and allow the operating system's background flush capabilities as it is more efficient.	long	9223372036854775807	[0,...]	log.flush.interval.ms	medium
follower.replication.throttled.replicas	A list of replicas for which log replication should be throttled on the follower side. The list should describe a set of replicas in the form [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:... or alternatively the wildcard '*' can be used to throttle all replicas for this topic.	list	""	[partitionId],[brokerId]:[partitionId],[brokerId]:...	follower.replication.throttled.replicas	medium
index.interval.bytes	This setting controls how frequently Kafka adds an index entry to it's offset index. The default setting ensures that we index a message roughly every 4096 bytes. More indexing allows reads to jump closer to the exact position in the log but makes the index larger. You probably don't need to change this.	int	4096	[0,...]	log.index.interval.bytes	medium
leader.replication.throttled.replicas	A list of replicas for which log replication should be throttled on the leader side. The list should describe a set of replicas in the form [PartitionId]:[BrokerId],[PartitionId]:[BrokerId]:... or alternatively the wildcard '*' can be used to throttle all replicas for this topic.	list	""	[partitionId],[brokerId]:[partitionId],[brokerId]:...	leader.replication.throttled.replicas	medium
max.message.bytes	The largest record batch size allowed by Kafka. If this is increased and there are consumers older than 0.10.2, the consumers' fetch size must also be increased so that the they can fetch record batches this large. In the latest message format version, records are always grouped into batches for efficiency. In previous message format versions, uncompressed records are not grouped into batches and this limit only applies to a single record in that case.	int	1000012	[0,...]	message.max.bytes	medium
message.format.version	Specify the message format version the broker will use to append messages to the logs. The value should be a valid ApiVersion. Some examples are: 0.8.2, 0.9.0.0, 0.10.0, check ApiVersion for more details. By setting a particular message format version, the user is certifying that all the existing messages on disk are smaller or equal than the specified version. Setting this value incorrectly will cause consumers with older versions to break as they will receive messages with a format that they don't understand.	string	1.0-IV0		log.message.format.version	medium
message.timestamp.difference.max.ms	The maximum difference allowed between the timestamp when a broker receives a message and the timestamp specified in the message. If message.timestamp.type=CreateTime, a message will be rejected if the difference in timestamp exceeds this threshold. This configuration is ignored if message.timestamp.type=LogAppendTime.	long	9223372036854775807	[0,...]	log.message.timestamp.difference.max.ms	medium
message.timestamp.type	Define whether the timestamp in the message is message create time or log append time. The value should be either `CreateTime` or `LogAppendTime`	string	CreateTime		log.message.timestamp.type	medium
min.cleanable.dirty.ratio	This configuration controls how frequently the log compactor will attempt to clean the log (assuming log compaction is enabled). By default we will avoid cleaning a log where more than 50% of the log has been compacted. This ratio bounds the maximum space wasted in the log by duplicates (at 50% at most 50% of the log could be duplicates). A higher ratio will mean fewer, more efficient cleanings but will mean more wasted space in the log.	double	0.5	[0,...,1]	log.cleaner.min.cleanable.ratio	medium
min.compaction.lag.ms	The minimum time a message will remain uncompacted in the log. Only applicable for logs that are being compacted.	long	0	[0,...]	log.cleaner.min.compaction.lag.ms	medium
min.insync.replicas	When a producer sets acks to "all" (or "-1"), this configuration specifies the minimum number of replicas that must acknowledge a write for the write to be considered successful. If this minimum cannot be met, then the producer will raise an exception (either NotEnoughReplicas or NotEnoughReplicasAfterAppend). When used together, min.insync.replicas and acks allow you to enforce greater durability guarantees. A typical scenario would be to create a topic with a replication factor of 3, set min.insync.replicas to 2, and produce with acks of "all". This will ensure that the producer raises an exception if a majority of replicas do not receive a write.	int	1	[1,...]	min.insync.replicas	medium
preallocate	True if we should preallocate the file on disk when creating a new log segment.	boolean	false		log.preallocate	medium
retention.bytes	如果我们使用“删除”保留策略，则此配置将控制分区（由日志段组成）的最大大小，在我们放弃旧的日志段释放空间之前，该分区可以增长到最大。默认情况下，没有大小限制只有一个时间限制。由于此限制是在分区级别执行的，请将其乘以分区数来计算主题保留（以字节为单位）。	长	-1		log.retention.bytes	中
retention.ms	如果我们使用“删除”保留策略，则此配置将控制保留日志的最长时间，然后放弃旧的日志段以释放空间。这代表了消费者必须快速阅读数据的SLA。	长	604800000		log.retention.ms	中
segment.bytes	此配置控制日志的段文件大小。保留和清理总是一次完成一个文件，因此较大的段大小意味着较少的文件，但对保留的控制较少。	INT	1073741824	[14，...]	log.segment.bytes	中
segment.index.bytes	此配置控制将偏移量映射到文件位置的索引大小。我们预先分配这个索引文件并且在日志滚动之后才缩小它。您通常不需要更改此设置。	INT	10485760	[0，...]	log.index.size.max.bytes	中
segment.jitter.ms	从预定的分段滚动时间中减去最大的随机抖动，以避免雷鸣般的分段滚动	长	0	[0，...]	log.roll.jitter.ms	中
segment.ms	此配置控制Kafka即使段文件未满也会强制日志滚动的时间段，以确保保留可以删除或压缩旧数据。	长	604800000	[0，...]	log.roll.ms	中
unclean.leader.election.enable	指示是否启用不在ISR集合中的副本作为最后的选择，即使这样做可能导致数据丢失。	布尔	假		unclean.leader.election.enable	中

3.4消费者配置

在0.9.0.0中，我们引入了新的Java消费者作为旧的基于Scala的简单和高级消费者的替代品。下面介绍新老用户的配置。

3.4.1新的消费者配置

以下是新消费者的配置：

名称	描述	类型	默认	有效值	重要性
bootstrap.servers	用于建立到Kafka集群的初始连接的主机/端口对列表。客户端将使用所有服务器，而不管在这里指定哪些服务器用于引导 - 该列表仅影响用于发现全套服务器的初始主机。这个清单应该在表格中host1:port1,host2:port2,...。由于这些服务器仅用于初始连接以发现完整的群集成员资格（可能会动态更改），因此此列表不必包含整套服务器（但可能需要多个服务器，以防服务器关闭）。	名单			高
key.deserializer	实现org.apache.kafka.common.serialization.Deserializer接口的密钥的反序列化器类。	类			高
value.deserializer	用于实现org.apache.kafka.common.serialization.Deserializer接口的值的反序列化器类。	类			高
fetch.min.bytes	服务器为获取请求返回的最小数据量。如果没有足够的数据可用，请求将等待那么多的数据在应答请求之前积累。1字节的默认设置意味着只要有一个字节的数据可用，或者提取请求超时等待数据到达，就会立即应答提取请求。将其设置为大于1的值将导致服务器等待大量的数据累积，这可以稍稍提高服务器吞吐量，但需要花费一些额外的延迟时间。	INT	1	[0，...]	高
group.id	标识此消费者所属的消费者群组的唯一字符串。如果消费者通过使用subscribe(topic)基于卡夫卡的偏移量管理策略来使用组管理功能，则此属性是必需的。	串	“”		高
heartbeat.interval.ms	在使用Kafka集团管理设施时，心跳与消费者协调员之间的预期时间。心跳是用来确保消费者的会议保持活跃，并促进新消费者加入或离开组时重新平衡。该值必须设置为低于session.timeout.ms，但通常应设置为不高于该值的1/3。它可以调整得更低，以控制正常再平衡的预期时间。	INT	3000		高
max.partition.fetch.bytes	服务器将返回每个分区的最大数据量。记录由用户批量提取。如果提取的第一个非空分区中的第一个记录批次大于此限制，则该批次仍将被返回，以确保用户可以取得进展。代理接受的最大记录批量大小通过message.max.bytes（代理配置）或max.message.bytes（主题配置）进行定义。请参阅fetch.max.bytes来限制消费者请求大小。	INT	1048576	[0，...]	高
session.timeout.ms	使用Kafka的组管理设施时，用于检测消费者失败的超时。消费者定期发送心跳来向经纪人表明其活跃度。如果代理在该会话超时到期之前没有收到心跳，那么代理将从该组中删除该消费者并启动重新平衡。请注意，该值必须在允许的范围内，正如代理配置中的group.min.session.timeout.msand所配置的那样group.max.session.timeout.ms。	INT	10000		高
ssl.key.password	密钥存储文件中的私钥密码。这对于客户端是可选的。	密码	空值		高
ssl.keystore.location	密钥存储文件的位置。这对客户端是可选的，可以用于客户端的双向认证。	串	空值		高
ssl.keystore.password	密钥存储文件的商店密码。这对客户端是可选的，只有在配置了ssl.keystore.location时才需要。	密码	空值		高
ssl.truststore.location	信任存储文件的位置。	串	空值		高
ssl.truststore.password	信任存储文件的密码。如果密码未设置，信任库的访问仍然可用，但完整性检查被禁用。	密码	空值		高
auto.offset.reset	在Kafka中没有初始偏移时，或者当前的偏移在服务器上不存在（例如，因为该数据已被删除），该怎么办：最早：自动将偏移量重置为最早的偏移量最新：自动将偏移量重置为最新的偏移量 none：如果消费者组没有找到先前的偏移量，则向消费者抛出异常其他任何事情：向消费者抛出异常。	串	最新	[最新，最早，没有]	中
connections.max.idle.ms	Close idle connections after the number of milliseconds specified by this config.	long	540000		medium
enable.auto.commit	If true the consumer's offset will be periodically committed in the background.	boolean	true		medium
exclude.internal.topics	Whether records from internal topics (such as offsets) should be exposed to the consumer. If set to true the only way to receive records from an internal topic is subscribing to it.	boolean	true		medium
fetch.max.bytes	服务器为获取请求而返回的最大数据量。记录由消费者批量提取，如果第一个非空分区中的第一个记录批次大于此值，则记录批次仍将被返回以确保消费者可以进行。因此，这不是一个绝对的最大值。代理接受的最大记录批量大小通过message.max.bytes（代理配置）或max.message.bytes（主题配置）进行定义。请注意，消费者并行执行多个提取。	INT	52428800	[0，...]	中
isolation.level	Controls how to read messages written transactionally. If set to read_committed, consumer.poll() will only return transactional messages which have been committed. If set to read_uncommitted' (the default), consumer.poll() will return all messages, even transactional messages which have been aborted. Non-transactional messages will be returned unconditionally in either mode. 消息将始终以偏移顺序返回。因此，在read_committed模式下，consumer.poll（）将只返回到最后一个稳定偏移量（LSO）的消息，这比第一个打开事务的偏移量小。特别是在属于正在进行的交易的消息之后出现的任何消息将被扣留，直到相关的交易完成。因此，read_committed消费者在飞行交易中将无法读取高水印。而且，当进入时 read_committed the seekToEnd method will return the LSO	串	READ_UNCOMMITTED	[read_committed，read_uncommitted]	中
max.poll.interval.ms	在使用消费者组管理时，调用poll（）之间的最大延迟。这提出了消费者在获取更多记录之前可以闲置的时间量的上界。如果在此超时到期之前未调用poll（），则认为使用者失败，并且组将重新平衡以将分区重新分配给其他成员。	INT	300000	[1，...]	中
max.poll.records	在一次调用poll（）中返回的最大记录数。	INT	500	[1，...]	中
partition.assignment.strategy	当使用组管理时，客户端将用于在客户实例之间分配分区所有权的分区分配策略的类名	名单	类org.apache.kafka.clients.consumer.RangeAssignor		中
receive.buffer.bytes	读取数据时使用的TCP接收缓冲区（SO_RCVBUF）的大小。如果值为-1，则将使用操作系统默认值。	INT	65536	[-1，...]	中
request.timeout.ms	配置控制客户端等待请求响应的最长时间。如果在超时过去之前未收到响应，则客户端将在必要时重新发送请求，或者如果重试耗尽，则请求失败。	INT	305000	[0，...]	中
sasl.jaas.config	用于JAAS配置文件使用的格式的SASL连接的JAAS登录上下文参数。这里描述JAAS配置文件格式。值的格式是：'（=）*;”	密码	空值		中
sasl.kerberos.service.name	Kafka运行的Kerberos主体名称。这可以在Kafka的JAAS配置或Kafka的配置中定义。	串	空值		中
sasl.mechanism	用于客户端连接的SASL机制。这可能是安全提供者可用的任何机制。GSSAPI是默认的机制。	串	GSSAPI		中
security.protocol	用于与经纪人沟通的协议。有效值为：PLAINTEXT，SSL，SASL_PLAINTEXT，SASL_SSL。	串	纯文本		中
send.buffer.bytes	发送数据时要使用的TCP发送缓冲区（SO_SNDBUF）的大小。如果值为-1，则将使用操作系统默认值。	INT	131072	[-1，...]	中
ssl.enabled.protocols	启用了SSL连接的协议列表。	名单	TLSv1.2工作，TLSv1.1，使用TLSv1		中
ssl.keystore.type	密钥存储文件的文件格式。这对于客户端是可选的。	串	JKS		中
ssl.protocol	用于生成SSLContext的SSL协议。默认设置是TLS，在大多数情况下这是很好的。最近的JVM中允许的值是TLS，TLSv1.1和TLSv1.2。较旧的JVM中可能支持SSL，SSLv2和SSLv3，但由于已知的安全漏洞，它们的使用不受欢迎。	串	TLS		中
ssl.provider	用于SSL连接的安全提供程序的名称。默认值是JVM的默认安全提供程序。	串	空值		中
ssl.truststore.type	信任存储文件的文件格式。	串	JKS		中
auto.commit.interval.ms	消费者偏移的频率以毫秒为单位自动提交给Kafka，如果enable.auto.commit设置为true。	INT	5000	[0，...]	低
check.crcs	自动检查消耗的记录的CRC32。这可以确保没有在线或磁盘损坏的消息发生。这个检查会增加一些开销，所以在寻求极高性能的情况下可能会被禁用。	布尔	真正		低
client.id	发出请求时传递给服务器的id字符串。这样做的目的是通过允许在服务器端请求日志中包含一个逻辑应用程序名称来跟踪请求的来源，而不仅仅是ip / port。	串	“”		低
fetch.max.wait.ms	如果没有足够的数据立即满足fetch.min.bytes给定的要求，服务器在应答提取请求之前将阻塞的最大时间量。	INT	500	[0，...]	低
interceptor.classes	用作拦截器的类的列表。实现org.apache.kafka.clients.consumer.ConsumerInterceptor接口允许你拦截（也可能是变异）消费者收到的记录。默认情况下，没有拦截器。	名单	空值		低
metadata.max.age.ms	以毫秒为单位的时间段之后，即使我们没有看到任何分区领导变化，以主动发现任何新的代理或分区，我们强制更新元数据。	长	300000	[0，...]	低
metric.reporters	用作度量记录的类的列表。实现org.apache.kafka.common.metrics.MetricsReporter接口允许插入将被通知新度量创建的类。JmxReporter始终包含在注册JMX统计信息中。	名单	“”		低
metrics.num.samples	维持用于计算度量的样本数量。	INT	2	[1，...]	低
metrics.recording.level	指标的最高记录级别。	串	信息	[信息，调试]	低
metrics.sample.window.ms	计算指标样本的时间窗口。	长	30000	[0，...]	低
reconnect.backoff.max.ms	重新连接到重复连接失败的代理程序时要等待的最长时间（以毫秒为单位）。如果提供的话，每个主机的退避将以指数方式增加，对于每个连续的连接失败，达到这个最大值。计算后退增加后，增加20％随机抖动以避免连接风暴。	长	1000	[0，...]	低
reconnect.backoff.ms	尝试重新连接到给定主机之前等待的基本时间。这避免了在一个紧密的循环中重复连接到主机。该退避适用于客户端向经纪人的所有连接尝试。	长	50	[0，...]	低
retry.backoff.ms	尝试重试对给定主题分区的失败请求之前等待的时间量。这样可以避免在某些故障情况下重复发送请求。	长	100	[0，...]	低
sasl.kerberos.kinit.cmd	Kerberos kinit命令路径。	串	在/ usr / bin中/ kinit命令		低
sasl.kerberos.min.time.before.relogin	登录线程在刷新尝试之间的休眠时间	长	60000		低
sasl.kerberos.ticket.renew.jitter	随机抖动增加到更新时间的百分比。	双	0.05		低
sasl.kerberos.ticket.renew.window.factor	登录线程将休眠，直到已经到达从上次刷新到票证到期的指定窗口时间因子，届时它将尝试更新票证。	双	0.8		低
ssl.cipher.suites	密码套件列表。这是用于使用TLS或SSL网络协议来协商网络连接的安全设置的认证，加密，MAC和密钥交换算法的命名组合。默认情况下，所有可用的密码套件都受支持。	名单	空值		低
ssl.endpoint.identification.algorithm	使用服务器证书验证服务器主机名的端点识别算法。	串	空值		低
ssl.keymanager.algorithm	密钥管理器工厂用于SSL连接的算法。信息范范范读预辛辛	串	SunX509		低
ssl.secure.random.implementation	用于SSL加密操作的SecureRandom PRNG实现。	串	空值		低
ssl.trustmanager.algorithm	信任管理器工厂用于SSL连接的算法。默认值是为Java虚拟机配置的信任管理器工厂算法。	串	PKIX		低

3.4.2老消费者配置

基本的老消费者配置如下：

group.id
zookeeper.connect

属性	默认	描述
group.id		唯一标识此消费者所属的消费者进程组的字符串。通过设置相同的组ID，多个进程表明它们都是同一个用户组的一部分。
zookeeper.connect		hostname:port以主机和端口为ZooKeeper服务器的主机和端口的形式指定ZooKeeper连接字符串。当ZooKeeper机器停机时，为了允许通过其他ZooKeeper节点进行连接，还可以在表单中指定多个主机hostname1:port1,hostname2:port2,hostname3:port3。服务器也可能有一个ZooKeeper chroot路径作为其ZooKeeper连接字符串的一部分，该连接字符串将其数据置于全局ZooKeeper命名空间的某个路径下。如果是这样，消费者应该在其连接字符串中使用相同的chroot路径。例如，给/chroot/path你一个chroot路径将给连接字符串hostname1:port1,hostname2:port2,hostname3:port3/chroot/path。
consumer.id	空值	如果没有设置，自动生成。
socket.timeout.ms	30 * 1000	网络请求的套接字超时。实际的超时设置将是max.fetch.wait + socket.timeout.ms。
socket.receive.buffer.bytes	64 * 1024	套接字接收缓冲区的网络请求
fetch.message.max.bytes	1024 * 1024	在每个提取请求中尝试为每个主题分区提取的消息的字节数。这些字节将被读入每个分区的内存，所以这有助于控制消费者使用的内存。获取请求大小必须至少与服务器允许的最大消息大小一样大，否则生产者可能发送大于消费者可以获取的消息。
num.consumer.fetchers	1	用于提取数据的数量提取器线程。
auto.commit.enable	真正	如果为true，则定期向ZooKeeper提交消费者已获取的消息的偏移量。当进程失败时，将使用此提交的偏移量作为新消费者开始的位置。
auto.commit.interval.ms	60 * 1000	消费者偏移量承诺给动物园管理员的频率（以毫秒为单位）。
queued.max.message.chunks	2	缓冲消耗的消息块的最大数量。每个块可以达到fetch.message.max.bytes。
rebalance.max.retries	4	当一个新的消费者加入一个消费者群体时，该组消费者试图“重新平衡”负载以将分区分配给每个消费者。如果在分配发生时该组消费者发生更改，则重新平衡将失败并重试。此设置控制放弃之前的最大尝试次数。
fetch.min.bytes	1	服务器为获取请求返回的最小数据量。如果没有足够的数据可用，请求将等待那么多的数据在应答请求之前积累。
fetch.wait.max.ms	100	如果没有足够的数据立即满足fetch.min.bytes，服务器在回答提取请求之前将阻塞的最大时间量
rebalance.backoff.ms	2000	Backoff time between retries during rebalance. If not set explicitly, the value in zookeeper.sync.time.ms is used.
refresh.leader.backoff.ms	200	Backoff time to wait before trying to determine the leader of a partition that has just lost its leader.
auto.offset.reset	largest	What to do when there is no initial offset in ZooKeeper or if an offset is out of range: * smallest : automatically reset the offset to the smallest offset * largest : automatically reset the offset to the largest offset * anything else: throw exception to the consumer
consumer.timeout.ms	-1	Throw a timeout exception to the consumer if no message is available for consumption after the specified interval
exclude.internal.topics	true	Whether messages from internal topics (such as offsets) should be exposed to the consumer.
client.id	group id value	The client id is a user-specified string sent in each request to help trace calls. It should logically identify the application making the request.
zookeeper.session.timeout.ms	6000	ZooKeeper session timeout. If the consumer fails to heartbeat to ZooKeeper for this period of time it is considered dead and a rebalance will occur.
zookeeper.connection.timeout.ms	6000	The max time that the client waits while establishing a connection to zookeeper.
zookeeper.sync.time.ms	2000	How far a ZK follower can be behind a ZK leader
offsets.storage	zookeeper	Select where offsets should be stored (zookeeper or kafka).
offsets.channel.backoff.ms	1000	The backoff period when reconnecting the offsets channel or retrying failed offset fetch/commit requests.
offsets.channel.socket.timeout.ms	10000	Socket timeout when reading responses for offset fetch/commit requests. This timeout is also used for ConsumerMetadata requests that are used to query for the offset manager.
offsets.commit.max.retries	5	Retry the offset commit up to this many times on failure. This retry count only applies to offset commits during shut-down. It does not apply to commits originating from the auto-commit thread. It also does not apply to attempts to query for the offset coordinator before committing offsets. i.e., if a consumer metadata request fails for any reason, it will be retried and that retry does not count toward this limit.
dual.commit.enabled	true	如果您使用“kafka”作为offsets.storage，则可以双向提交到ZooKeeper的偏移量（除了Kafka）。从基于zookeeper的偏移量存储迁移到基于kafka的偏移量存储时，这是必需的。对于任何给定的消费者群体，在该群组中的所有实例已经迁移到向代理（而不是直接向ZooKeeper）提交偏移的新版本之后，将其关闭是安全的。
partition.assignment.strategy	范围	在“范围”或“循环”策略之间进行选择，以将分区分配给消费者流。循环分区分配器将所有可用的分区和所有可用的使用者线程放在一起。然后继续执行从分区到消费者线程的循环分配。如果所有消费者实例的订阅都是相同的，那么分区将被均匀分配。（即，所有消费者线程中的分区所有权计数将在一个正好为1的增量内）。只有在以下情况下才允许循环分配：（a）每个主题在消费者实例中具有相同数量的流（b）订阅的主题对于组内的每个消费者实例是相同的。范围分区在每个主题的基础上工作。对于每个主题，我们按数字顺序排列可用的分区，消费者以字典顺序排列。然后，我们将分区数除以消费者流（线程）的总数，以确定分配给每个消费者的分区数。如果它不均匀分配，那么前几个消费者将有一个额外的分区。

关于消费者配置的更多细节可以在scala类中找到kafka.consumer.ConsumerConfig。

3.5卡夫卡连接配置

以下是Kafka Connect框架的配置。

名称	描述	类型	默认	有效值	重要性
config.storage.topic	存储连接器配置的Kafka主题的名称	串			高
group.id	标识此工作人员所属的Connect群集组的唯一字符串。	串			高
key.converter	转换器类用于在Kafka Connect格式和写入Kafka的序列化表单之间进行转换。这将控制写入Kafka或从Kafka读取的消息中的密钥格式，因为这与连接器无关，所以它允许任何连接器使用任何序列化格式。常见格式的例子包括JSON和Avro。	类			高
offset.storage.topic	存储连接器偏移量的Kafka主题的名称	串			高
status.storage.topic	连接器和任务状态存储在卡夫卡主题的名称	串			高
value.converter	转换器类用于在Kafka Connect格式和写入Kafka的序列化表单之间进行转换。这将控制写入Kafka或从Kafka读取的消息中的值的格式，因为这与连接器无关，所以它允许任何连接器使用任何序列化格式。常见格式的例子包括JSON和Avro。	类			高
internal.key.converter	转换器类用于在Kafka Connect格式和写入Kafka的序列化表单之间进行转换。这将控制写入Kafka或从Kafka读取的消息中的密钥格式，因为这与连接器无关，所以它允许任何连接器使用任何序列化格式。常见格式的例子包括JSON和Avro。此设置控制框架使用的内部簿记数据的格式，例如配置和偏移，因此用户通常可以使用任何有效的Converter实现。	类			低
internal.value.converter	转换器类用于在Kafka Connect格式和写入Kafka的序列化表单之间进行转换。这将控制写入Kafka或从Kafka读取的消息中的值的格式，因为这与连接器无关，所以它允许任何连接器使用任何序列化格式。常见格式的例子包括JSON和Avro。此设置控制框架使用的内部簿记数据的格式，例如配置和偏移，因此用户通常可以使用任何有效的Converter实现。	类			低
bootstrap.servers	用于建立到Kafka集群的初始连接的主机/端口对列表。客户端将使用所有服务器，而不管在这里指定哪些服务器用于引导 - 该列表仅影响用于发现全套服务器的初始主机。这个清单应该在表格中host1:port1,host2:port2,...。由于这些服务器仅用于初始连接以发现完整的群集成员资格（可能会动态更改），因此此列表不必包含整套服务器（但可能需要多个服务器，以防服务器关闭）。	名单	本地主机：9092		高
heartbeat.interval.ms	在使用Kafka的团队管理设施时，心跳与团队协调员之间的预期时间。心跳信号用于确保工作人员的会话保持活动状态，并便于新成员加入或离开组时重新平衡。该值必须设置为低于session.timeout.ms，但通常应设置为不高于该值的1/3。它可以调整得更低，以控制正常再平衡的预期时间。	INT	3000		高
rebalance.timeout.ms	一旦重新平衡开始，每个工人加入该组的最长时间。这基本上是所有任务清除任何未决数据和提交偏移所需时间的限制。如果超时超时，则工作人员将被从组中移除，这将导致偏移提交失败。	INT	60000		高
session.timeout.ms	用于检测工作人员失败的超时。工人周期性地发送心跳来向经纪人表明其活跃性。如果代理在该会话超时到期之前没有收到检测信号，代理将从该组中删除该工作人员并启动重新平衡。请注意，该值必须在允许的范围内，正如代理配置中的group.min.session.timeout.msand所配置的那样group.max.session.timeout.ms。	INT	10000		高
ssl.key.password	密钥存储文件中的私钥密码。这对于客户端是可选的。	密码	空值		高
ssl.keystore.location	密钥存储文件的位置。这对客户端是可选的，可以用于客户端的双向认证。	串	空值		高
ssl.keystore.password	密钥存储文件的商店密码。这对客户端是可选的，只有在配置了ssl.keystore.location时才需要。	密码	空值		高
ssl.truststore.location	信任存储文件的位置。	串	空值		高
ssl.truststore.password	信任存储文件的密码。如果密码未设置，信任库的访问仍然可用，但完整性检查被禁用。	密码	空值		高
connections.max.idle.ms	在此配置指定的毫秒数之后关闭空闲连接。	长	540000		中
receive.buffer.bytes	读取数据时使用的TCP接收缓冲区（SO_RCVBUF）的大小。如果值为-1，则将使用操作系统默认值。	INT	32768	[0，...]	中
request.timeout.ms	配置控制客户端等待请求响应的最长时间。如果在超时过去之前未收到响应，则客户端将在必要时重新发送请求，或者如果重试耗尽，则请求失败。	INT	40000	[0，...]	中
sasl.jaas.config	用于JAAS配置文件使用的格式的SASL连接的JAAS登录上下文参数。这里描述JAAS配置文件格式。值的格式是：'（=）*;”	密码	空值		中
sasl.kerberos.service.name	Kafka运行的Kerberos主体名称。这可以在Kafka的JAAS配置或Kafka的配置中定义。	串	空值		中
sasl.mechanism	用于客户端连接的SASL机制。这可能是安全提供者可用的任何机制。GSSAPI是默认的机制。	串	GSSAPI		中
security.protocol	用于与经纪人沟通的协议。有效值为：PLAINTEXT，SSL，SASL_PLAINTEXT，SASL_SSL。	串	纯文本		中
send.buffer.bytes	发送数据时要使用的TCP发送缓冲区（SO_SNDBUF）的大小。如果值为-1，则将使用操作系统默认值。	INT	131072	[0，...]	中
ssl.enabled.protocols	启用了SSL连接的协议列表。	名单	TLSv1.2工作，TLSv1.1，使用TLSv1		中
ssl.keystore.type	密钥存储文件的文件格式。这对于客户端是可选的。	串	JKS		中
ssl.protocol	用于生成SSLContext的SSL协议。默认设置是TLS，在大多数情况下这是很好的。最近的JVM中允许的值是TLS，TLSv1.1和TLSv1.2。较旧的JVM中可能支持SSL，SSLv2和SSLv3，但由于已知的安全漏洞，它们的使用不受欢迎。	串	TLS		中
ssl.provider	用于SSL连接的安全提供程序的名称。默认值是JVM的默认安全提供程序。	串	空值		中
ssl.truststore.type	信任存储文件的文件格式。	串	JKS		中
worker.sync.timeout.ms	当员工与其他员工不同步并需要重新同步配置时，请在放弃之前等待这段时间，离开组并等待退休时间，然后再重新加入。	INT	3000		中
worker.unsync.backoff.ms	当员工与其他员工不同步并且无法赶上worker.sync.timeout.ms时，在重新加入之前将Connect群集保留很长时间。	INT	300000		中
access.control.allow.methods	通过设置Access-Control-Allow-Methods标头来设置跨源请求所支持的方法。Access-Control-Allow-Methods头的缺省值允许GET，POST和HEAD的交叉源请求。	串	“”		低
access.control.allow.origin	值到访问控制允许来源头设置为REST API requests.To启用跨源访问，这设置为应该被允许访问的API，或应用程序的域“*”，以允许从任何存取域。默认值只允许从REST API的域进行访问。	串	“”		低
client.id	发出请求时传递给服务器的id字符串。这样做的目的是通过允许在服务器端请求日志中包含一个逻辑应用程序名称来跟踪请求的来源，而不仅仅是ip / port。	串	“”		低
config.storage.replication.factor	创建配置存储主题时使用的复制因子	短	3	[1，...]	低
metadata.max.age.ms	以毫秒为单位的时间段之后，即使我们没有看到任何分区领导变化，以主动发现任何新的代理或分区，我们强制更新元数据。	长	300000	[0，...]	低
metric.reporters	用作度量记录的类的列表。实现org.apache.kafka.common.metrics.MetricsReporter接口允许插入将被通知新度量创建的类。JmxReporter始终包含在注册JMX统计信息中。	名单	“”		低
metrics.num.samples	维持用于计算度量的样本数量。	INT	2	[1，...]	低
metrics.recording.level	指标的最高记录级别。	串	信息	[信息，调试]	低
metrics.sample.window.ms	计算指标样本的时间窗口。	长	30000	[0，...]	低
offset.flush.interval.ms	尝试为任务提交抵消的时间间隔。	长	60000		低
offset.flush.timeout.ms	在取消进程并恢复将来尝试提交的偏移数据之前，等待记录刷新的最大毫秒数以及将提交的偏移数据提交到偏移存储的最大毫秒数。	长	5000		低
offset.storage.partitions	创建偏移量存储主题时使用的分区数量	INT	25	[1，...]	低
offset.storage.replication.factor	创建偏移量存储主题时使用的复制因子	短	3	[1，...]	低
plugin.path	包含插件（连接器，转换器，转换）的由逗号（，）分隔的路径列表。该列表应包含顶级目录，其中包括以下任意组合：a）立即包含带有插件及其依赖项的jar的目录b）带有插件及其依赖项的uber-jar项目c）立即包含插件类的包目录结构依赖关系注意：将遵循符号链接来发现依赖关系或插件。例子：plugin.path = / usr / local / share / java，/ usr / local / share / kafka / plugins，/ opt / connectors	名单	空值		低
reconnect.backoff.max.ms	重新连接到重复连接失败的代理程序时要等待的最长时间（以毫秒为单位）。如果提供的话，每个主机的退避将以指数方式增加，对于每个连续的连接失败，达到这个最大值。计算后退增加后，增加20％随机抖动以避免连接风暴。	长	1000	[0，...]	低
reconnect.backoff.ms	尝试重新连接到给定主机之前等待的基本时间。这避免了在一个紧密的循环中重复连接到主机。该退避适用于客户端向经纪人的所有连接尝试。	长	50	[0，...]	低
rest.advertised.host.name	如果设置了，则这是将要发给其他工作人员连接的主机名。	串	空值		低
rest.advertised.port	如果设置了这个，那么这个端口将被发给其他工作人员连接。	INT	空值		低
rest.host.name	REST API的主机名。如果这设置，它将只绑定到这个接口。	串	空值		低
rest.port	REST API侦听的端口。	INT	8083		低
retry.backoff.ms	尝试重试对给定主题分区的失败请求之前等待的时间量。这样可以避免在某些故障情况下重复发送请求。	长	100	[0，...]	低
sasl.kerberos.kinit.cmd	Kerberos kinit命令路径。	串	在/ usr / bin中/ kinit命令		低
sasl.kerberos.min.time.before.relogin	登录线程在刷新尝试之间的休眠时间	长	60000		低
sasl.kerberos.ticket.renew.jitter	随机抖动增加到更新时间的百分比。	双	0.05		低
sasl.kerberos.ticket.renew.window.factor	登录线程将休眠，直到已经到达从上次刷新到票证到期的指定窗口时间因子，届时它将尝试更新票证。	双	0.8		低
ssl.cipher.suites	密码套件列表。这是用于使用TLS或SSL网络协议来协商网络连接的安全设置的认证，加密，MAC和密钥交换算法的命名组合。默认情况下，所有可用的密码套件都受支持。	名单	空值		低
ssl.endpoint.identification.algorithm	使用服务器证书验证服务器主机名的端点识别算法。	串	空值		低
ssl.keymanager.algorithm	密钥管理器工厂用于SSL连接的算法。信息范范范读预辛辛	串	SunX509		低
ssl.secure.random.implementation	用于SSL加密操作的SecureRandom PRNG实现。	串	空值		低
ssl.trustmanager.algorithm	信任管理器工厂用于SSL连接的算法。默认值是为Java虚拟机配置的信任管理器工厂算法。	串	PKIX		低
status.storage.partitions	创建状态存储主题时使用的分区数量	INT	五	[1，...]	低
status.storage.replication.factor	创建状态存储主题时使用的复制因子	短	3	[1，...]	低
task.shutdown.graceful.timeout.ms	等待任务正常关闭的时间。这是总时间，而不是每个任务。所有任务都有关闭触发，然后按顺序等待。	长	5000		低

3.6卡夫卡流配置

以下是Kafka Streams客户端库的配置。

名称	描述	类型	默认	有效值	重要性
application.id	流处理应用程序的标识符。在Kafka集群中必须是唯一的。它被用作1）默认的客户端ID前缀，2）用于成员资格管理的组ID，3）变更记录主题前缀。	串			高
bootstrap.servers	用于建立到Kafka集群的初始连接的主机/端口对列表。客户端将使用所有服务器，而不管在这里指定哪些服务器用于引导 - 该列表仅影响用于发现全套服务器的初始主机。这个清单应该在表格中host1:port1,host2:port2,...。由于这些服务器仅用于初始连接以发现完整的群集成员资格（可能会动态更改），因此此列表不必包含整套服务器（但可能需要多个服务器，以防服务器关闭）。	名单			高
replication.factor	流处理应用程序创建的更改日志主题和重新分区主题的复制因子。	INT	1		高
state.dir	州商店的目录位置。	串	的/ tmp /卡夫卡流		高
cache.max.bytes.buffering	在所有线程中用于缓冲的最大内存字节数	长	10485760	[0，...]	中
client.id	用于内部消费者，生产者和还原消费者的客户端ID的ID前缀字符串，模式为“-StreamThread- - ”。	串	“”		中
default.deserialization.exception.handler	实现org.apache.kafka.streams.errors.DeserializationExceptionHandler接口的异常处理类。	类	org.apache.kafka.streams.errors.LogAndFailExceptionHandler		中
default.key.serde	实现org.apache.kafka.common.serialization.Serde接口的键的默认序列化器/反序列化器类。	类	org.apache.kafka.common.serialization.Serdes $ ByteArraySerde		中
default.timestamp.extractor	实现org.apache.kafka.streams.processor.TimestampExtractor接口的默认时间戳提取器类。	类	org.apache.kafka.streams.processor.FailOnInvalidTimestamp		中
default.value.serde	实现org.apache.kafka.common.serialization.Serde接口的值的默认序列化器/反序列化器类。	类	org.apache.kafka.common.serialization.Serdes $ ByteArraySerde		中
num.standby.replicas	每个任务的备用副本数量。	INT	0		中
num.stream.threads	执行流处理的线程数。	INT	1		中
processing.guarantee	应该使用的处理保证。可能的值是at_least_once（默认）和exactly_once。	串	至少一次	[at_least_once，exactly_once]	中
security.protocol	用于与经纪人沟通的协议。有效值为：PLAINTEXT，SSL，SASL_PLAINTEXT，SASL_SSL。	串	纯文本		中
application.server	指向嵌入式用户定义端点的主机：端口对，可用于在单个KafkaStreams应用程序中发现状态存储的位置	串	“”		低
buffered.records.per.partition	每个分区缓冲的最大记录数。	INT	1000		低
commit.interval.ms	处理器位置的保存频率。（注意，如果'processing.guarantee'设置为'exactly_once'，则默认值为100，否则默认值为30000。	长	30000		低
connections.max.idle.ms	在此配置指定的毫秒数之后关闭空闲连接。	长	540000		低
key.serde	用于实现org.apache.kafka.common.serialization.Serde接口的键的序列化器/反序列化器类。这个配置不推荐使用，default.key.serde而是使用	类	空值		低
metadata.max.age.ms	以毫秒为单位的时间段之后，即使我们没有看到任何分区领导变化，以主动发现任何新的代理或分区，我们强制更新元数据。	长	300000	[0，...]	低
metric.reporters	用作度量记录的类的列表。实现org.apache.kafka.common.metrics.MetricsReporter接口允许插入将被通知新度量创建的类。JmxReporter始终包含在注册JMX统计信息中。	名单	“”		低
metrics.num.samples	维持用于计算度量的样本数量。	INT	2	[1，...]	低
metrics.recording.level	指标的最高记录级别。	串	信息	[信息，调试]	低
metrics.sample.window.ms	计算指标样本的时间窗口。	长	30000	[0，...]	低
partition.grouper	实现org.apache.kafka.streams.processor.PartitionGrouper接口的分区石斑鱼类。	类	org.apache.kafka.streams.processor.DefaultPartitionGrouper		低
poll.ms	阻止等待输入的时间量（以毫秒为单位）。	长	100		低
receive.buffer.bytes	读取数据时使用的TCP接收缓冲区（SO_RCVBUF）的大小。如果值为-1，则将使用操作系统默认值。	INT	32768	[0，...]	低
reconnect.backoff.max.ms	重新连接到重复连接失败的代理程序时要等待的最长时间（以毫秒为单位）。如果提供的话，每个主机的退避将以指数方式增加，对于每个连续的连接失败，达到这个最大值。计算后退增加后，增加20％随机抖动以避免连接风暴。	长	1000	[0，...]	低
reconnect.backoff.ms	尝试重新连接到给定主机之前等待的基本时间。这避免了在一个紧密的循环中重复连接到主机。该退避适用于客户端向经纪人的所有连接尝试。	长	50	[0，...]	低
request.timeout.ms	配置控制客户端等待请求响应的最长时间。如果在超时过去之前未收到响应，则客户端将在必要时重新发送请求，或者如果重试耗尽，则请求失败。	INT	40000	[0，...]	低
retry.backoff.ms	尝试重试对给定主题分区的失败请求之前等待的时间量。这样可以避免在某些故障情况下重复发送请求。	长	100	[0，...]	低
rocksdb.config.setter	岩石数据库配置设置类或类名称，实现org.apache.kafka.streams.state.RocksDBConfigSetter接口	类	空值		低
send.buffer.bytes	发送数据时要使用的TCP发送缓冲区（SO_SNDBUF）的大小。如果值为-1，则将使用操作系统默认值。	INT	131072	[0，...]	低
state.cleanup.delay.ms	在删除分区迁移后的状态之前等待的时间（以毫秒为单位）。只有至少state.cleanup.delay.ms状态的目录才会被删除	长	600000		低
timestamp.extractor	实现org.apache.kafka.streams.processor.TimestampExtractor接口的时间戳提取器类。这个配置不推荐使用，default.timestamp.extractor而是使用	类	空值		低
value.serde	用于实现org.apache.kafka.common.serialization.Serde接口的值的序列化器/反序列化器类。这个配置不推荐使用，default.value.serde而是使用	类	空值		低
windowstore.changelog.additional.retention.ms	添加到Windows维护组，以确保数据不会过早地从日志中删除。允许时钟漂移。默认为1天	长	86400000		低
zookeeper.connect	Zookeeper为Kafka主题管理连接字符串。这个配置不推荐使用，因为Streams API不再使用Zookeeper，所以会被忽略。	串	“”		低

3.7 AdminClient配置

以下是Kafka Admin客户端库的配置。

名称	描述	类型	默认	有效值	重要性
bootstrap.servers	用于建立到Kafka集群的初始连接的主机/端口对列表。客户端将使用所有服务器，而不管在这里指定哪些服务器用于引导 - 该列表仅影响用于发现全套服务器的初始主机。这个清单应该在表格中host1:port1,host2:port2,...。由于这些服务器仅用于初始连接以发现完整的群集成员资格（可能会动态更改），因此此列表不必包含整套服务器（但可能需要多个服务器，以防服务器关闭）。	名单			高
ssl.key.password	密钥存储文件中的私钥密码。这对于客户端是可选的。	密码	空值		高
ssl.keystore.location	密钥存储文件的位置。这对客户端是可选的，可以用于客户端的双向认证。	串	空值		高
ssl.keystore.password	密钥存储文件的商店密码。这对客户端是可选的，只有在配置了ssl.keystore.location时才需要。	密码	空值		高
ssl.truststore.location	信任存储文件的位置。	串	空值		高
ssl.truststore.password	信任存储文件的密码。如果密码未设置，信任库的访问仍然可用，但完整性检查被禁用。	密码	空值		高
client.id	发出请求时传递给服务器的id字符串。这样做的目的是通过允许在服务器端请求日志中包含一个逻辑应用程序名称来跟踪请求的来源，而不仅仅是ip / port。	串	“”		中
connections.max.idle.ms	在此配置指定的毫秒数之后关闭空闲连接。	长	300000		中
receive.buffer.bytes	读取数据时使用的TCP接收缓冲区（SO_RCVBUF）的大小。如果值为-1，则将使用操作系统默认值。	INT	65536	[-1，...]	中
request.timeout.ms	配置控制客户端等待请求响应的最长时间。如果在超时过去之前未收到响应，则客户端将在必要时重新发送请求，或者如果重试耗尽，则请求失败。	INT	120000	[0，...]	中
sasl.jaas.config	用于JAAS配置文件使用的格式的SASL连接的JAAS登录上下文参数。这里描述JAAS配置文件格式。值的格式是：'（=）*;”	密码	空值		中
sasl.kerberos.service.name	Kafka运行的Kerberos主体名称。这可以在Kafka的JAAS配置或Kafka的配置中定义。	串	空值		中
sasl.mechanism	SASL mechanism used for client connections. This may be any mechanism for which a security provider is available. GSSAPI is the default mechanism.	string	GSSAPI		medium
security.protocol	Protocol used to communicate with brokers. Valid values are: PLAINTEXT, SSL, SASL_PLAINTEXT, SASL_SSL.	string	PLAINTEXT		medium
send.buffer.bytes	The size of the TCP send buffer (SO_SNDBUF) to use when sending data. If the value is -1, the OS default will be used.	int	131072	[-1,...]	medium
ssl.enabled.protocols	The list of protocols enabled for SSL connections.	list	TLSv1.2,TLSv1.1,TLSv1		medium
ssl.keystore.type	The file format of the key store file. This is optional for client.	string	JKS		medium
ssl.protocol	The SSL protocol used to generate the SSLContext. Default setting is TLS, which is fine for most cases. Allowed values in recent JVMs are TLS, TLSv1.1 and TLSv1.2. SSL, SSLv2 and SSLv3 may be supported in older JVMs, but their usage is discouraged due to known security vulnerabilities.	string	TLS		medium
ssl.provider	The name of the security provider used for SSL connections. Default value is the default security provider of the JVM.	string	null		medium
ssl.truststore.type	The file format of the trust store file.	string	JKS		medium
metadata.max.age.ms	The period of time in milliseconds after which we force a refresh of metadata even if we haven't seen any partition leadership changes to proactively discover any new brokers or partitions.	long	300000	[0,...]	low
metric.reporters	A list of classes to use as metrics reporters. Implementing the org.apache.kafka.common.metrics.MetricsReporter interface allows plugging in classes that will be notified of new metric creation. The JmxReporter is always included to register JMX statistics.	list	""		low
metrics.num.samples	The number of samples maintained to compute metrics.	int	2	[1,...]	low
metrics.recording.level	The highest recording level for metrics.	string	INFO	[INFO, DEBUG]	low
metrics.sample.window.ms	The window of time a metrics sample is computed over.	long	30000	[0,...]	low
reconnect.backoff.max.ms	The maximum amount of time in milliseconds to wait when reconnecting to a broker that has repeatedly failed to connect. If provided, the backoff per host will increase exponentially for each consecutive connection failure, up to this maximum. After calculating the backoff increase, 20% random jitter is added to avoid connection storms.	long	1000	[0,...]	low
reconnect.backoff.ms	The base amount of time to wait before attempting to reconnect to a given host. This avoids repeatedly connecting to a host in a tight loop. This backoff applies to all connection attempts by the client to a broker.	long	50	[0,...]	low
retries	The maximum number of times to retry a call before failing it.	int	5	[0,...]	low
retry.backoff.ms	The amount of time to wait before attempting to retry a failed request. This avoids repeatedly sending requests in a tight loop under some failure scenarios.	long	100	[0,...]	low
sasl.kerberos.kinit.cmd	Kerberos kinit命令路径。	串	在/ usr / bin中/ kinit命令		低
sasl.kerberos.min.time.before.relogin	登录线程在刷新尝试之间的休眠时间	长	60000		低
sasl.kerberos.ticket.renew.jitter	随机抖动增加到更新时间的百分比。	双	0.05		低
sasl.kerberos.ticket.renew.window.factor	登录线程将休眠，直到已经到达从上次刷新到票证到期的指定窗口时间因子，届时它将尝试更新票证。	双	0.8		低
ssl.cipher.suites	密码套件列表。这是用于使用TLS或SSL网络协议来协商网络连接的安全设置的认证，加密，MAC和密钥交换算法的命名组合。默认情况下，所有可用的密码套件都受支持。	名单	空值		低
ssl.endpoint.identification.algorithm	使用服务器证书验证服务器主机名的端点识别算法。	串	空值		低
ssl.keymanager.algorithm	密钥管理器工厂用于SSL连接的算法。信息范范范读预辛辛	串	SunX509		低
ssl.secure.random.implementation	用于SSL加密操作的SecureRandom PRNG实现。	串	空值		低
ssl.trustmanager.algorithm	信任管理器工厂用于SSL连接的算法。默认值是为Java虚拟机配置的信任管理器工厂算法。	串	PKIX		低

4.设计

4.1动机

我们设计的Kafka能够作为一个统一的平台来处理大公司可能拥有的所有实时数据馈送。要做到这一点，我们必须考虑相当广泛的用例。

它将不得不具有高吞吐量来支持高容量事件流，例如实时日志聚合。

它将需要正常处理大量的数据积压，以便能够支持来自离线系统的周期性数据加载。

这也意味着系统将不得不处理低延迟传递来处理更传统的消息传递用例。

我们希望支持对这些提要进行分区，分布式，实时处理，以创建新的派生提要。这激发了我们的分区和消费者模式。

最后，在流被送入其他数据系统进行服务的情况下，我们知道系统必须能够在出现机器故障时保证容错。

支持这些用途导致我们设计了一些独特的元素，更类似于数据库日志而不是传统的消息传递系统。我们将在下面的章节中概述一些设计元素。

不要害怕文件系统！

卡夫卡在很大程度上依赖文件系统来存储和缓存消息。人们普遍认为，“磁盘速度慢”使人们怀疑一个持久的结构可以提供有竞争力的表现。实际上，磁盘比人们所期望的要慢得多，速度也要快得多，这取决于它们的使用方式。一个设计合理的磁盘结构通常可以和网络一样快。

关于磁盘性能的关键事实是，硬盘的吞吐量与过去十年的磁盘搜索的延迟已经不同了。因此，使用6个7200rpm SATA RAID-5阵列的JBOD配置上的线性写入性能约为600MB / sec，但随机写入的性能仅约为100k / sec，相差6000多倍。这些线性读取和写入是所有使用模式中最可预测的，并且由操作系统进行了大量优化。现代操作系统提供预读和后写技术，以大块为单位预取数据，并将较小的逻辑写入大型物理写入。关于这个问题的进一步讨论可以在这个ACM队列文章中找到。他们真的找到了顺序磁盘访问在某些情况下可能比随机内存访问更快！

为了弥补这种性能差异，现代操作系统在使用主内存进行磁盘缓存方面变得越来越积极。现代操作系统将愉快地将所有空闲内存转移到磁盘高速缓存，并在回收内存时性能降低。所有的磁盘读写操作都将通过这个统一的缓存。如果不使用直接I / O，此功能将无法轻松关闭，因此即使进程维护数据的进程内缓存，该数据也可能会在操作系统页面缓存中复制，从而有效地存储所有内容两次。

而且，我们正在建立在JVM的基础之上，任何花时间使用Java内存的人都知道两件事情：

对象的内存开销很高，通常会使所存储数据的大小加倍（或更糟糕）。
随着堆内数据的增加，Java垃圾收集变得越来越复杂和缓慢。

由于使用文件系统和依赖页面缓存的这些因素优于维护内存缓存或其他结构，因此我们至少使可用缓存翻了一番，方法是自动访问所有可用内存，并且可能再次通过存储紧凑字节结构而不是单个对象。这样做会导致在32GB的机器上高达28-30GB的缓存，而不受GC惩罚。此外，即使服务重新启动，该缓存也会保持温暖，而进程内缓存将需要在内存中重建（对于10GB的缓存可能需要10分钟），否则将需要以完全冷的缓存开始（这可能意味着糟糕的初始表现）。这也大大简化了代码，因为所有保持高速缓存和文件系统之间一致性的逻辑现在都在OS中，这往往比一次性的进行中的尝试更有效和更正确地做到这一点。如果您的磁盘使用情况支持线性读取，则预读使用每个磁盘读取的有用数据有效地预先填充此缓存。

这表明一个非常简单的设计：当我们在空间不足的时候，不是尽可能地维护内存，而是把文件系统全部清理出来，我们反过来这样做。所有数据立即写入文件系统的持久日志，而不必冲刷到磁盘。实际上，这只是意味着它被转移到内核的页面缓存中。

这种以页面缓存为中心的设计风格在这里的一个关于Varnish设计的文章中描述（伴随着一种健康的傲慢态度）。

时间不变

消息传递系统中使用的持久数据结构通常是具有关联的BTree或其他通用随机访问数据结构的按消费者队列来维护关于消息的元数据。BTrees是可用的最通用的数据结构，可以在消息传递系统中支持各种各样的事务性和非事务性语义。但它们的成本相当高：Btree操作是O（logN）。通常O（log N）被认为基本上等同于常量时间，但是对于磁盘操作来说这不是真的。磁盘寻道是在10毫秒的时间来进行的，每个磁盘一次只能做一个寻道，所以并行性是有限的。因此，即使是少数磁盘寻找导致非常高的开销。由于存储系统将非常快速的缓存操作与非常慢的物理磁盘操作混合，

直观地说，持久队列可以建立在简单的读取上，并附加到文件中，这与记录解决方案的情况相同。这个结构的优点是所有的操作都是O（1），读操作不会阻止写操作或者彼此之间的操作。由于性能与数据大小完全分离，这具有明显的性能优势 - 现在一台服务器可以充分利用大量廉价，低转速的1 + TB SATA驱动器。虽然它们的搜寻性能很差，但这些驱动器在大型读写方面的性能还是可以接受的，达到了三分之一的价格和三倍的容量。

在没有任何性能损失的情况下访问几乎无限制的磁盘空间意味着我们可以提供通常在消息传递系统中找不到的一些功能例如，在Kafka中，我们可以保留相对较长的时间（比如说一个星期），而不是试图在消费后马上删除消息。正如我们将要描述的，这给消费者带来了很大的灵活性。

4.3效率

我们已经付出了很大的努力效率。我们的主要用例之一是处理网络活动数据，这是非常高的数据量：每个页面视图可能会产生几十个写入。此外，我们假设发布的每条消息都被至少一个消费者（通常是很多消费者）读取，因此我们努力使消费尽可能便宜。

我们还发现，从建立和运行一系列类似系统的经验来看，效率是实现多租户有效运营的关键。如果下游基础设施服务由于应用程序使用量小而容易成为瓶颈，那么这些小的改变往往会产生问题。通过非常快的速度，我们可以帮助确保应用程序在基础架构之前在负载下翻车。当尝试运行支持集中式群集上数十个或数百个应用程序的集中式服务时，这一点尤为重要，因为使用模式的变化几乎每天都在发生。

我们在上一节讨论了磁盘效率。一旦消除了较差的磁盘访问模式，在这种类型的系统中有两个常见的低效率原因：太多的小I / O操作和过多的字节复制。

客户端和服务器之间以及服务器自己的持久操作中都会发生小I / O问题。

为了避免这种情况，我们的协议是建立在一个“消息集”抽象的基础上，自然将消息分组在一起。这允许网络请求将消息分组在一起，并分摊网络往返的开销，而不是一次发送单个消息。服务器依次将大块消息附加到其日志中，并且消费者一次获取大的线性块。

这个简单的优化产生了数量级的加速。批量导致更大的网络数据包，更大的顺序磁盘操作，连续的内存块等等，所有这些都允许Kafka将随机消息写入的突发流转换为流向消费者的线性写入。

另一个低效率是在字节复制。在低信息率这不是一个问题，但在负载下的影响是显着的。为了避免这种情况，我们使用由生产者，代理和消费者共享的标准二进制消息格式（因此可以在它们之间不加修改地传送数据块）。

由代理维护的消息日志本身就是一个文件目录，每个文件都由一系列消息集合填充，这些消息集合已经以生产者和消费者使用的相同格式写入磁盘。保持这种通用格式可以优化最重要的操作：持久日志块的网络传输。现代的unix操作系统提供了一个高度优化的代码路径，用于将数据从页面缓存转移到套接字; 在Linux中，这是通过sendfile系统调用完成的。

要理解sendfile的影响，了解数据从文件传输到套接字的常见数据路径非常重要：

操作系统将数据从磁盘读取到内核空间的pagecache中
应用程序从内核空间读取数据到用户空间缓冲区
应用程序将数据写回内核空间到套接字缓冲区
操作系统将数据从套接字缓冲区复制到通过网络发送的NIC缓冲区

这显然是低效的，有四个副本和两个系统调用。使用sendfile，通过允许操作系统将数据从pagecache直接发送到网络，可以避免重新复制。所以在这个优化的路径中，只需要最终拷贝到NIC缓冲区。

我们期望一个共同的用例在一个主题上成为多个消费者。使用上面的零拷贝优化，数据被复制到页面缓存中一次，并在每次使用时被重用，而不是被存储在内存中，并且每次被读取时拷贝到用户空间。这允许消息以接近网络连接限制的速率消耗。

页面缓存和发送文件的组合意味着，在消费者大多被抓住的卡夫卡群集中，您将看不到磁盘上的读取活动，因为它们将完全从缓存中提供数据。

有关sendfile和Java中零拷贝支持的更多背景信息，请参阅本文。

端到端的批量压缩

在某些情况下，瓶颈实际上不是CPU或磁盘，而是网络带宽。对于需要通过广域网在数据中心之间发送消息的数据管道尤其如此。当然，用户总是可以一次压缩一个消息，而不需要Kafka的任何支持，但是这会导致非常差的压缩率，因为冗余的多少是由于相同类型的消息之间的重复（例如， JSON或Web日志中的用户代理或公共字符串值）。有效的压缩需要一起压缩多个消息，而不是单独压缩每个消息。

Kafka以高效的批处理格式支持这一点。一批消息可以压缩在一起并以这种形式发送到服务器。这批消息将以压缩格式写入，并将保持压缩在日志中，只会由消费者解压缩。

Kafka支持GZIP，Snappy和LZ4压缩协议。有关压缩的更多细节可以在这里找到。

4.4生产者

负载均衡

生产者将数据直接发送给作为分区领导者的代理，而不需要任何中间路由层。为了帮助生产者做到这一点，所有的Kafka节点都可以回答关于哪些服务器是活着的元数据的请求，以及主题的分区的领导在哪里给定的时间以允许生产者适当地指示其请求。

客户端控制它将消息发布到哪个分区。这可以随机完成，实现一种随机负载平衡，也可以通过一些语义分区功能完成。我们通过允许用户指定一个键进行分区，并使用它来散列到一个分区（如果需要的话，也可以选择覆盖分区函数），从而公开接口进行语义分区。例如，如果选择的密钥是用户ID，则给定用户的所有数据将被发送到相同的分区。这反过来将允许消费者对他们的消费做出当地的假设。这种分区方式明确地设计为允许在消费者中进行局部敏感的处理。

异步发送

批次是效率的重要推动力之一，为了实现批量生产，卡夫卡生产商将试图在内存中积累数据，并在一个请求中发送大批量的数据。批处理可以被配置为累加不超过固定数量的消息并且不超过某个固定的延迟限制（比如64k或10ms）。这允许发送更多字节的累积，并且在服务器上几个较大的I / O操作。这种缓冲是可配置的，并提供了一种机制来折中少量额外的延迟以获得更好的吞吐量。

有关配置的详细信息和生产者的api可以在文档的其他地方找到。

4.5消费者

Kafka消费者通过向经销商发出“获取”请求来引导他们想要消费的分区。消费者用每个请求在日志中指定它的偏移量，并从该位置接收一大块日志。因此，消费者对这个位置具有重要的控制，并且如果需要的话可以倒转以重新消费数据。

推与拉

我们考虑的一个最初的问题是，消费者是否应该从经纪商或经纪商那里获取数据，以便将数据推送给消费者。在这方面，卡夫卡采用了一种更为传统的设计方式，由大多数消息系统共享，数据从生产者推送给经纪人，由消费者从经纪人那里提取。一些以日志为中心的系统，如Scribe和 Apache Flume，遵循一个非常不同的推送路径，数据被推送到下游。这两种方法都有优点和缺点。然而，基于推送的系统难以处理不同的消费者，因为经纪人控制数据传输的速度。目标通常是消费者能够以最大可能的速度消费; 不幸的是，在推动系统中，这意味着当消费率低于生产率（本质上是拒绝服务攻击）时，消费者倾向于被压倒。基于拉动的系统具有更好的属性，消费者只要落后就赶上。这可以通过消费者可以指示它被压倒的某种退避协议来缓解，但让转移率充分利用（但从来没有过度利用）的消费者似乎比棘手。以前以这种方式构建系统的尝试使我们得以采用更传统的拉式模型。

基于拉式系统的另一个优点是，它可以将数据发送给消费者，基于推送的系统必须选择立即发送请求，或者累积更多的数据，然后在不知道下游消费者是否能够立即处理的情况下发送。如果调整为低延迟，则这将导致一次只发送单个消息，以便传输结束被缓冲，这是浪费的。基于拉式的设计修复了这个问题，因为消费者总是将所有可用的消息拉到日志中的当前位置（或达到某个可配置的最大大小）之后。所以人们可以获得最佳的配料而不会引入不必要的延迟

一个天真的基于拉式的系统的缺点是，如果经纪人没有数据，消费者可能会在一个紧密的循环中结束投票，有效地忙于等待数据到达。为了避免这种情况，我们在我们的pull请求中有一些参数，它们允许消费者请求以“长轮询”的方式进行阻塞，等待数据到达（并且可选地等待，直到给定数量的字节可用以确保大的传输大小）。

你可以想象其他可能的设计，只会拉，端到端。制片人会在当地写一个当地的日志，经纪人会从消费者那里抽出来。经常提出一个类似的“存储和转发”生产者。这是有趣的，但我们觉得不是很适合我们有成千上万的生产者的目标用例。我们在大规模运行持久数据系统的经验使我们感到，在许多应用程序中涉及系统中数以千计的磁盘实际上不会使事情变得更加可靠，而且会成为一个噩梦般的操作。在实践中，我们发现我们可以大规模地运行一个拥有强大SLA的流水线，而不需要生产者持久性。

消费者地位

跟踪已经消耗的东西，令人惊讶的是，消息系统的关键性能点之一。

大多数消息传递系统都保留关于代理消费的消息的元数据。也就是说，当消息被发送给消费者时，经纪人要么立即在本地记录该事实，要么等待消费者的确认。这是一个相当直观的选择，实际上对於单个机器服务器来说，不清楚这个状态可以去哪里。由于在许多消息传递系统中用于存储的数据结构规模较小，因此这也是一个实用的选择 - 由于代理知道消耗的是什么，它可以立即删除它，保持数据量小。

也许不明显的是，让经纪人和消费者就所消费的东西达成一致并不是一个小问题。如果代理记录作为消息消耗立即将其通过网络交给了每一个时间，那么如果消费者无法处理的消息（比如，因为它崩溃或请求超时或其他）该消息将会丢失。为了解决这个问题，许多消息传递系统增加了一个确认功能，这意味着消息只在被发送时被标记为发送而不被消费。代理等待来自消费者的特定确认以将消息记录为消费。这个策略解决了丢失信息的问题，但是却产生了新的问题。首先，如果消费者在消息发送失败之前处理消息，那么消息将被消费两次。第二个问题是性能问题，现在，代理必须保持每个消息的多个状态（首先锁定它，以便不会再次发出消息，然后将其标记为永久消耗，以便将其删除）。棘手的问题必须得到处理，比如如何处理被发送但未被确认的消息。

卡夫卡处理这个不同。我们的主题被分成一组完全有序的分区，每个分区在任何给定的时间都被每个订阅消费者组中的一个消费者消费。这意味着消费者在每个分区中的位置只是一个整数，即要消耗的下一个消息的偏移量。这使得所消耗的状态非常小，每个分区只有一个数字。这个状态可以定期检查点。这使消息确认的等价物非常便宜。

这个决定有一个好处。消费者可以故意倒回到旧的偏移量并重新使用数据。这违反了队列的共同合同，但是对于许多消费者来说却是一个必不可少的特征。例如，如果消费者代码有一个错误，并且在一些消息被消费之后被发现，则消费者可以在错误修复后重新使用这些消息。

离线数据加载

可伸缩的持久性允许消费者仅仅周期性地消费的可能性，诸如批量数据加载，其周期性地将数据批量加载到诸如Hadoop或关系数据仓库之类的离线系统中。

在Hadoop的情况下，我们通过在单个映射任务上分割负载来并行化数据负载，每个节点/主题/分区组合一个负载，在负载中允许完全并行化。Hadoop提供了任务管理功能，失败的任务可以重新启动，而没有重复数据的危险，只需从原始位置重新启动即可。

4.6消息传递语义

现在我们对生产者和消费者如何工作有一些了解，让我们来讨论一下Kafka在生产者和消费者之间提供的语义保证。显然，可以提供多种可能的消息传递保证：

最多一次 -消息可能会丢失，但永远不会重新发送。
至少一次 -消息永远不会丢失，但可以重新传递。
恰恰一次 - 这就是人们真正想要的，每个信息只传递一次。

值得注意的是，这分成两个问题：发布消息的持久性保证以及消费消息时的保证。

许多系统声称提供“恰好一次”的交付语义，但重要的是要阅读细则，这些声明大多是误导性的（即它们不转化为消费者或生产者可能失败的情况，消费者进程，或写入磁盘的数据可能丢失的情况）。

卡夫卡的语义是直截了当的。发布消息时，我们将消息的概念“提交”到日志中。一旦发布的消息被提交，只要复制写入该消息的分区的代理保持“活动”状态，它就不会丢失。提交的消息的定义，活动分区以及我们试图处理哪些类型的失败的描述将在下一节中更详细地描述。信息内的预读亦作亦读信息如果生产者尝试发布消息并遇到网络错误，则不能确定在提交消息之前或之后是否发生此错误。

在0.11.0.0之前，如果一个生产者没有收到一个指示消息已经提交的响应，那么除了重新发送消息之外别无选择。这提供了至少一次的传送语义，因为如果原始请求实际上已经成功，则在重新发送期间可以再次将消息写入日志。自0.11.0.0开始，Kafka生产者也支持一个幂等递送选项，保证重新发送不会在日志中导致重复条目。为了达到这个目的，代理人为每个生产者分配一个ID，并使用生产者发送的序列号和每一个消息去重复消息。也从0.11.0.0开始，生产者支持使用事务类语义将消息发送到多个主题分区的能力：即，或者所有的消息都被成功写入或者没有消息。这个主要用例恰好在卡夫卡话题之间进行一次处理（如下所述）。

并不是所有的用例都需要这样的强力保证对于对延迟敏感的用途，我们允许生产者指定它想要的耐久性级别。如果生产者指定它想要等待提交的消息，则可以采用10ms的量级。然而，制作者也可以指定它想要完全异步地执行发送，或者它只想等到领导者（但不一定是跟随者）才有消息。

现在让我们从消费者的角度来描述语义。所有副本都具有相同的日志和相同的偏移量。消费者控制在这个日志中的位置。如果消费者没有崩溃，它可以将这个位置存储在内存中，但是如果消费者失败了，我们希望这个主题分区被另一个进程接管，那么新进程需要选择一个合适的位置来开始处理。假设消费者读取一些消息 - 它具有处理消息和更新其位置的多个选项。

它可以读取消息，然后将其位置保存在日志中，最后处理消息。在这种情况下，消费者进程在保存其位置之后但在保存其消息处理的输出之前可能会崩溃。在这种情况下，接管处理的过程将从保存的位置开始，即使在该位置之前的一些消息还没有被处理。这对应于“最多一次”的语义，如在消费者失败的情况下可能不会被处理。
它可以读取消息，处理消息，并最终保存它的位置。在这种情况下，处理消息之后但在保存其位置之前，消费者进程可能会崩溃。在这种情况下，当新进程接管它收到的前几个消息时，已经被处理了。在消费者失败的情况下，这对应于“至少一次”的语义。在许多情况下，消息都有一个主键，所以更新是幂等的（接收相同的消息两次，只是用另一个副本覆盖一条记录）。

那么究竟是一次语义（即你真正想要的东西）呢？当从一个卡夫卡话题消费，并产生到另一个话题（如卡夫卡流应用程序），我们可以利用上面提到的0.11.0.0中的新事务生成器功能。消费者的位置作为消息存储在主题中，所以我们可以在与接收处理的数据的输出主题相同的事务中向Kafka写入偏移量。如果交易被中止，则消费者的位置将恢复到其旧值，并且根据其“隔离级别”，输出主题上产生的数据对其他消费者不可见。在默认的“read_uncommitted”隔离级别中，消费者即使是中止事务的一部分，所有消息都是可见的，但是在“read_committed”中，消费者只会从已提交的事务（以及任何不是的交易）。

写入外部系统时，限制在于需要将消费者的位置与实际存储为输出的位置进行协调。实现这一目标的经典方法是在消费者位置的存储和消费者输出的存储之间引入两阶段提交。但是，这可以更简单地处理，并且通常通过让消费者将其偏移存储在与其输出相同的位置来进行。这样做更好，因为消费者可能想要写入的许多输出系统不支持两阶段提交。作为一个例子，考虑一个 Kafka连接连接器，它在HDFS中填充数据以及读取数据的偏移量，以确保数据和偏移量都被更新，或者两者都不是。对于许多其他需要这些更强的语义的数据系统，我们也遵循类似的模式，并且对于这些数据系统，消息没有允许重复数据删除的主键。

因此，有效地，Kafka支持在Kafka Streams中一次交付，并且在Kafka主题之间传输和处理数据时，事务性生产者/消费者通常可用于提供准确一次的交付。其他目的地系统的一次交付通常需要与这些系统合作，但是Kafka提供了实现这种可行的补偿（参见Kafka Connect）。否则，Kafka默认保证至少一次交付，并允许用户在处理一批消息之前，通过禁止生产者重试和在消费者中提交补偿来实施至多一次交付。

4.7复制

Kafka通过可配置数量的服务器复制每个主题分区的日志（您可以在逐个主题的基础上设置此复制因子）。这样，当群集中的服务器出现故障时，可以自动故障转移到这些副本，以便在发生故障时保持可用状态。

其他消息传递系统提供了一些与复制有关的功能，但在我们（完全有偏见的）看来，这似乎是一个不太常用的东西，而且有很大的缺点：从属处于非活动状态，吞吐量受到严重影响，繁琐的手动配置等等。Kafka默认使用复制，实际上我们将未复制的主题实现为复制因子为1的复制主题。

复制单位是主题分区。在非失败条件下，卡夫卡的每个分区都有一个单独的领导者和零个或更多的追随者。包括领导者的副本总数构成复制因素。所有的读写操作都转到分区的领导。通常情况下，中间商比中间商多得多，而且领导者在经纪商之间平均分配。追随者的日志与领导者的日志相同 - 都有相同顺序的消息和消息（当然，在任何给定的时间，领导者可能在其日志结尾处有几条尚未复制的消息）。

追随者像正常的卡夫卡消费者一样消费领导者的消息，并将他们应用到他们自己的日志中。让追随者从领导者身上取得好成绩，可以让追随者自然地把日志条目分配到日志中。

与大多数分布式系统一样，自动处理故障需要精确定义节点“活跃”意味着什么。对于卡夫卡节点的生存有两个条件

节点必须能够维护与ZooKeeper的会话（通过ZooKeeper的心跳机制）
如果它是一个奴隶，它必须复制发生在领导者上的写作，而不是落后于“太远”

我们将满足这两个条件的节点称为“同步”，以避免“活着”或“失败”的模糊性。领导跟踪“同步”节点的集合。如果追随者死亡，被卡住或落后，领导将从同步副本列表中删除它。停滞和滞后复制品的确定由replica.lag.time.max.ms配置控制。

在分布式系统术语中，我们只尝试处理节点突然停止工作，然后恢复（可能不知道已经死亡）的失败/恢复模式。Kafka不处理所谓的“拜占庭式”的故障，其中节点产生任意或恶意的反应（可能是由于错误或犯规）。

现在我们可以更准确地定义，当该分区的所有同步副本将其应用于其日志时，将认为该消息已被提交。只有承诺的消息才会被发送给消费者。这意味着消费者不必担心如果领导者失败，可能会看到可能丢失的消息。另一方面，生产者可以选择是否等待消息被执行，这取决于他们在等待时间和耐久性之间的权衡。这个首选项由生产者使用的acks设置控制。请注意，主题有一个“最小数量”的同步副本的设置，当生产者请求确认消息已写入全套同步副本时，将检查这些副本。

卡夫卡提供的保证是，只要至少有一个同步副本在任何时间存在，就不会丢失承诺的消息。

在短暂的故障切换期后，卡夫卡将保持可用状态，但在出现网络分区的情况下可能无法保持可用状态。

复制日志：法定人数，ISR和状态机（哦，我的！）

卡夫卡分区的核心是一个复制日志。复制日志是分布式数据系统中最基本的原语之一，实现它的方法很多。其他系统可以使用复制的日志作为实现其他分布式系统状态的原语。

一个复制日志按照一系列值的顺序（通常是对日志条目编号0,1,2，...）进行建模。有很多方法可以实现这一点，但最简单和最快的方法是选择提供给它的值的排序的领导者。只要领导者还活着，所有的追随者只需要复制价值和领导者选择的命令。

当然，如果领导不失败，我们就不需要追随者！当领导者死亡时，我们需要从追随者中选择一个新的领导者。但追随者本身可能落后或崩溃，所以我们必须确保我们选择一个最新的追随者。日志复制算法必须提供的基本保证是，如果我们告诉客户一个消息被提交，并且领导失败，我们选择的新领导也必须有这个消息。这产生了一个折衷：如果领导者在宣布承诺之前等待更多的追随者承认消息，那么将会有更多潜在的可选领导者。

如果您选择所需的确认数量以及必须比较的日志数量来选择一个领导者，以确保重叠，则称为定额。

这种权衡的一个常见方法是在投票决定和领导者选举中使用多数票。这不是卡夫卡所做的，但是我们仍然可以通过探索来了解这个权衡。假设我们有2个f +1副本。如果f +1副本必须在领导者声明提交之前接收到消息，并且如果我们通过从至少f +1个副本中选择具有最完整日志的跟随者来选择新的领导者，则不超过f失败，领导者保证有所有承诺的信息。这是因为在任何f+1副本，必须至少有一个副本包含所有已提交的邮件。这个副本的日志将是最完整的，因此将被选为新的领导者。每个算法都必须处理许多其他细节（例如，精确定义什么使得日志更加完整，确保领导者失败期间的日志一致性或更改副本集中的服务器集），但是现在我们将忽略这些细节。

这种多数表决方法有一个非常好的属性：延迟是依赖于只有最快的服务器。也就是说，如果复制因子是3，则等待时间由更快的从属者而不是较慢的从属者确定。

这个系列有很多种算法，包括ZooKeeper的 Zab， Raft和Viewstamped Replication。我们知道Kafka的实际实现最类似的学术出版物是来自Microsoft的PacificA。

The downside of majority vote is that it doesn't take many failures to leave you with no electable leaders. To tolerate one failure requires three copies of the data, and to tolerate two failures requires five copies of the data. In our experience having only enough redundancy to tolerate a single failure is not enough for a practical system, but doing every write five times, with 5x the disk space requirements and 1/5th the throughput, is not very practical for large volume data problems. This is likely why quorum algorithms more commonly appear for shared cluster configuration such as ZooKeeper but are less common for primary data storage. For example in HDFS the namenode's high-availability feature is built on a majority-vote-based journal, but this more expensive approach is not used for the data itself.

卡夫卡采取了一种稍微不同的方法来选择法定人数。卡夫卡不是多数投票，而是动态地维护一组被引导到领导者的同步复制品（ISR）。只有这一组的成员才有资格当选领导人。写入Kafka分区不会被视为提交，直到所有的同步副本收到写入。这个ISR集合在ZooKeeper发生变化时会被持久化。正因为如此，ISR中的任何复制品都有资格当选领导者。这是卡夫卡使用模式的一个重要因素，其中有很多分区，确保领导力平衡是重要的。有了这个ISR模型和f + 1副本，一个Kafka主题可以容忍f故障，而不会丢失承诺的消息。

对于我们希望处理的大多数用例，我们认为这种权衡是合理的。在实践中，为了容忍f失败，大多数投票和ISR方法都将等待相同数量的副本在提交消息之前确认（例如，在一次失败后仍然存在，大多数法定人数需要三个副本和一个确认，ISR方法需要两个副本和一个确认）。在没有最慢服务器的情况下提交的能力是大多数投票方法的一个优点。但是，我们认为通过允许客户端选择是否阻塞消息提交来改善，并且由于所需的复制因子较低而产生的额外的吞吐量和磁盘空间是值得的。

另一个重要的设计区别是，Kafka不要求崩溃的节点恢复所有的数据。在这个空间中的复制算法依赖于存在“稳定存储”的情况并不少见，这种“稳定存储”在没有潜在的一致性违反的情况下在任何故障恢复情况下都不会丢失。这个假设有两个主要的问题。首先，磁盘错误是我们在永久性数据系统的实际操作中观察到的最常见的问题，并且它们通常不会使数据保持原样。其次，即使这不是问题，我们也不希望在每次写入时都要求使用fsync来保证一致性，因为这会使性能降低两到三个数量级。我们允许副本重新加入ISR的协议确保了在重新加入之前，

不洁的领导人选：如果他们都死了呢？

请注意，Kafka关于数据丢失的保证取决于至少有一个副本保持同步。如果复制分区的所有节点都死亡，则此保证不再成立。

然而，一个实际的系统需要做一些合理的事情，当所有的副本死亡。如果你不幸发生这种情况，重要的是要考虑会发生什么。有两种行为可以实现：

等待ISR的副本重新回到生活中，并选择这个副本作为领导者（希望它仍然拥有所有的数据）。
选择第一个复制品（不一定在ISR中）作为领导者复活。

这是可用性和一致性之间的简单折衷。如果我们在ISR中等待副本，那么只要这些副本停机，我们将保持不可用状态。如果这样的复制品被毁坏或者他们的数据丢失了，那么我们永远是失败的。另一方面，如果一个不同步的复制品恢复生机，并且我们允许它成为领导者，那么它的日志就成为真相的来源，即使它不能保证每一个提交的信息都是如此。默认情况下，Kafka选择第二种策略，并且当ISR中的所有副本都已经死掉时，选择可能不一致的副本。可以使用配置属性unclean.leader.election.enable来禁用此行为，以支持停机时间优于不一致的用例。

这种困境并不是卡夫卡所特有的。它存在于任何法定人数的计划中。例如，在大多数投票计划中，如果大多数服务器遭受永久性故障，那么您必须选择丢失100％的数据，或者通过将现有服务器上剩下的内容作为新的事实来源来破坏一致性。

可用性和耐久性保证

写给Kafka时，制作者可以选择是否等待消息被0,1或全部（-1）复制品确认。请注意，“所有副本确认”并不保证已分配副本的全套已收到消息。默认情况下，当acks = all时，只要所有当前的同步副本收到消息，确认就会发生。例如，如果一个主题配置了只有两个副本，一个失败（即只有一个同步副本保留），那么指定acks = all的写入将会成功。但是，如果剩余副本也失败，这些写入可能会丢失。尽管这确保了分区的最大可用性，但是对于偏好耐久性而不是可用性的一些用户，这种行为可能是不希望的。因此，

禁用不干净的领导者选举 - 如果所有副本都不可用，那么分区将保持不可用，直到最近的领导者再次可用。这有效地避免了消息丢失的风险。请参阅上一节有关不洁领导人选举的澄清。
指定最小的ISR大小 - 如果ISR的大小超过某个最小值，分区将只接受写入操作，以防止仅写入单个副本的消息丢失，而后者将不可用。这个设置只有在生产者使用acks = all的情况下才会生效，并且保证这个消息至少被许多in-sync副本确认。此设置提供了一致性和可用性之间的折中。对于最小ISR大小的更高设置保证了更好的一致性，因为信息被保证写入更多的副本，这减少了丢失的可能性。但是，这会降低可用性，因为如果同步副本的数量低于最小阈值，则分区将无法写入。

副本管理

以上关于复制日志的讨论确实只涵盖了单个日志，即一个主题分区。然而，一个Kafka集群将管理数百或数千个这样的分区。我们尝试以循环方式平衡集群内的分区，以避免在少量节点上集中高容量主题的所有分区。同样，我们试图平衡领导力，使每个节点成为其分区比例份额的领导者。

优化领导层选举过程也是重要的，因为这是不可用的关键窗口。领导者选举的一个天真的实现将最终运行每个分区的选举为该节点失败时托管节点的所有分区运行。相反，我们选择其中一个经纪人作为“控制者”。该控制器检测代理级别的故障，并负责更改故障代理中所有受影响的分区的负责人。结果是，我们可以将许多所需的领导层变更通知批量化，这使得选举过程对于大量分区而言要便宜得多并且速度更快。如果控制者失败，其中一个幸存的经纪人将成为新的控制者。

4.8日志压缩

日志压缩可确保Kafka始终至少为单个主题分区的数据日志中的每个消息密钥保留最后一个已知值。它解决了用例和场景，例如在应用程序崩溃或系统故障之后恢复状态，或者在运行维护期间重新启动应用程序之后重新加载缓存。让我们更详细地介绍这些用例，然后描述压缩是如何工作的。

到目前为止，我们只描述了更简单的数据保留方法，在一段固定的时间之后丢弃旧的日志数据，或者日志达到某个预定的大小。这适用于时间事件数据，例如记录每个记录独立的地方。然而，重要的一类数据流是对键控，可变数据（例如对数据库表的更改）的更改日志。

我们来讨论一个这样的流的具体例子。假设我们有一个包含用户邮箱地址的主题，每当用户更新他们的电子邮件地址时，我们都会使用他们的用户ID作为主键向此主题发送消息。现在说我们在一段时间内为id为123的用户发送以下消息，每个消息对应于电子邮件地址的改变（其他id的消息被省略）：

五

123 => [email protected]

日志压缩为我们提供了一个更细粒度的保留机制，以便我们保证至少保留每个主键（例如[email protected]）的最后更新。通过这样做，我们保证日志包含每个密钥的最终值的完整快照，而不仅仅是最近更改的密钥。这意味着下游消费者可以从这个主题中恢复自己的状态，而不必保留所有更改的完整日志。

我们先看几个有用的用例，然后看看它是如何使用的。

数据库更改订阅。通常需要在多个数据系统中拥有一个数据集，而且这些系统中的一个往往是某种数据库（RDBMS或可能是一个新开发的键值存储）。例如，您可能有一个数据库，一个缓存，一个搜索集群和一个Hadoop集群。每次对数据库的更改都需要反映在缓存，搜索群集中，最终在Hadoop中。在只处理实时更新的情况下，您只需要最近的日志。但是，如果您希望能够重新加载缓存或恢复失败的搜索节点，则可能需要完整的数据集。
事件采购。这是一种应用程序设计风格，它将查询处理与应用程序设计协同定位，并使用变更日志作为应用程序的主要存储。
日志记录高可用性。执行本地计算的进程可以通过注销对其本地状态所做的更改来实现容错，以便另一个进程可以重新加载这些更改并在出现故障时继续执行。一个具体的例子是在流查询系统中处理计数，聚合和其他“按类”处理。Samza是一个实时的流处理框架，正是为了这个目的而使用这个特性。

在这些情况下，主要需要处理变化的实时馈送，但是偶尔当机器崩溃或需要重新加载或重新处理数据时，需要满载。日志压缩允许将这两个用例从相同的支持主题中提取出来。本博客文章更详细地介绍了这种日志的使用方式。

总的想法很简单。如果我们有无限的日志保留，并且记录了上述情况下的每一个变化，那么我们就会从第一次开始时就捕获到系统的状态。使用这个完整的日志，我们可以通过重放日志中的前N个记录来恢复到任何时间点。这个假设的完整日志对于更新单个记录多次的系统来说并不是很实用，因为即使对于稳定的数据集，日志也将不受限制地增长。其扔掉旧的更新简单的日志保留机制约束的空间，但该日志已不再恢复方式的当前状态，现在可以从日志的开头不再恢复再现旧更新可能不会在所有拍摄的当前状态。

日志压缩是提供更细粒度的每记录保留的机制，而不是更粗粒度的基于时间的保留。这个想法是有选择地删除我们有一个更新的更新与相同的主键的记录。这样，日志保证至少有每个密钥的最后一个状态。

此保留策略可以按每个主题进行设置，因此单个群集可以有一些主题，其中的保留是按大小或时间强制执行的，其他主题是通过压缩保留保留的主题。

这种功能受到LinkedIn最古老，最成功的基础架构之一 - 数据库变更日志缓存服务Databus的启发。与大多数日志结构存储系统不同的是，Kafka是为订阅而建立的，它组织数据以实现快速的线性读写。与Databus不同的是，Kafka充当真实来源商店，所以即使在上游数据源不可重播的情况下也是如此。

日志压缩基础

这是一个高级图片，显示每个消息的偏移量的Kafka日志的逻辑结构。

日志的头部与传统的Kafka日志相同。它具有密集的连续偏移并保留所有消息。日志压缩添加了一个处理日志尾部的选项。上面的图片显示了一个压缩尾巴的日志。请注意，日志尾部的消息保留了第一次写入时分配的原始偏移量 - 这些消息从不改变。还要注意的是，即使具有该偏移量的消息已被压缩，所有偏移仍然保留在日志中的有效位置; 在这种情况下，这个位置与日志中出现的下一个最高偏移无法区分。例如，在上面的图片中，偏移量36,37和38都是等同的位置，并且从这些偏移量的任何一个开始的读取将返回从38开始的消息集合。

压缩也允许删除。具有密钥和空有效负载的消息将被视为从日志中删除。这个删除标记会导致任何先前的消息被删除（如同任何带有该密钥的新消息一样），但是删除标记是特殊的，因为在一段时间之后它们自己将被清除出日志以释放空间。删除不再保留的时间点被标记为上图中的“删除保留点”。

压缩是通过定期重新复制日志段在后台完成的。清洗不会阻塞读取，并且可以被限制使用不超过可配置数量的I / O吞吐量，以避免影响生产者和消费者。压缩日志段的实际过程如下所示：

日志压缩提供了什么保证？

日志压缩保证以下内容：

任何一个处于日志头部的消费者都会看到每个被写入的消息; 这些消息将有连续的偏移量。min.compaction.lag.ms可以使用主题来保证写入消息之前必须经过的最短时间长度，然后才能被压缩。即它提供了每个消息将保留在（未压缩的）头部多长时间的下限。
消息的排序始终保持不变。压缩永远不会重新排序消息，只是删除一些。
消息的偏移不会改变。它是日志中位置的永久标识符。
从日志开始的任何消费者将至少看到他们写入的所有记录的最终状态。此外，只要用户在小于主题delete.retention.ms设置的时间（默认值是24小时）到达日志头部，所有删除标记都将被显示。换句话说：因为删除标记的删除与读取同时发生，所以消费者可能错过删除标记，如果它滞后的话delete.retention.ms。

日志压缩细节

日志压缩是由日志清理器处理的，日志清理器是后台线程池，用于重新记录日志段文件，删除其日志头部出现的记录。每个压缩机线程的工作原理如下：

它选择日志头与日志尾比率最高的日志
它为日志头部中的每个键创建最后偏移的简明摘要
它从头到尾复制日志中的日志，删除日志中稍后出现的日志。新的，干净的段被立即交换到日志中，所需的额外磁盘空间只是一个额外的日志段（不是日志的完整副本）。
日志头的总结实质上只是一个空间紧凑的散列表。它每个条目使用正好24个字节。因此，使用8GB清理缓冲区时，一次清理迭代就可以清理大约366GB的日志头（假设有1K条消息）。

配置日志清理器

日志清理器默认是启用的。这将启动更干净的线程池。要在特定主题上启用日志清理，可以添加特定于日志的属性

1	log.cleanup.policy=compact

这可以在主题创建时或使用alter topic命令完成。

日志清理器可以配置为保留日志的未压缩“头”的最小量。这是通过设置压缩时间滞后来实现的。

1	log.cleaner.min.compaction.lag.ms

这可以用来防止比最小消息时间更新的消息被压缩。如果没有设置，除了最后一个段（即当前正在写入的段）之外，所有日志段都可以压缩。即使所有消息都比最小压缩时间滞后更早，活动段也不会被压缩。

这里描述了更清洁的配置。

4.9配额

Kafka群集有能力对请求执行配额以控制客户端使用的代理资源。卡夫卡经纪人可以为每组共享配额的客户端实施两种类型的客户配额：

网络带宽配额定义了字节率阈值（从0.9开始）
请求速率配额将CPU利用率阈值定义为网络和I / O线程的百分比（自0.11开始）

为什么配额是必要的？

生产者和消费者有可能以非常高的速度生产/消费非常大量的数据或产生请求，从而垄断经纪人资源，导致网络饱和，并且通常会阻碍其他客户和经纪人本身。拥有配额可以防范这些问题，而在大型多租户群集中，一小部分表现不佳的客户端可能会降低用户体验良好的用户体验，这一点尤为重要。事实上，当运行Kafka作为一项服务时，甚至可以根据约定的合同强制执行API限制。

客户群

Kafka客户端的身份是代表安全集群中经过身份验证的用户的用户主体。在支持未经身份验证的客户端的集群中，用户主体是由代理使用可配置选择的未经身份验证的用户的分组PrincipalBuilder。Client-id是由客户端应用程序选择的具有有意义名称的客户端的逻辑分组。元组（user，client-id）定义了共享用户主体和客户机id的安全逻辑组的客户机。

配额可以应用于（用户，客户端ID），用户或客户端组。对于给定的连接，将应用与连接匹配的最具体的配额。配额组的所有连接共享为组配置的配额。例如，如果（user =“test-user”，client-id =“test-client”）的产品配额为10MB / sec，则在用户“test-user”的所有生产者实例中与客户端 - ID“测试客户端”。

配额配置

可以为（用户，客户端ID），用户和客户端组定义配额配置。可以在任何需要更高（或更低）配额的配额级别上覆盖默认配额。该机制类似于每个主题日志配置覆盖。用户和（用户，客户端ID）配额覆盖写入/ config / users下的ZooKeeper ，客户端配额覆盖写在/ config / clients下。这些覆盖被所有经纪人读取，并立即生效。这使我们可以更改配额，而无需执行整个群集的滚动重新启动。详情请看这里。每个组的默认配额也可以使用相同的机制动态更新。

配额配置的优先顺序是：

/配置/用户/ <用户> /客户端/ <客户端ID>
/配置/用户/ <用户> /客户端/ <默认>
/配置/用户/ <用户>
/配置/用户/ <默认> /客户端/ <客户端ID>
/配置/用户/ <默认> /客户端/ <默认>
/配置/用户/ <默认>
/配置/客户端/ <客户端ID>
/配置/客户端/ <默认>

代理属性（quota.producer.default，quota.consumer.default）也可用于为客户端组设置网络带宽配额的默认值。这些属性已被弃用，将在以后的版本中删除。客户端ID的默认配额可以在Zookeeper中设置，类似于其他配额覆盖和默认设置。

网络带宽配额

网络带宽配额定义为每组共享配额的客户端的字节速率阈值。默认情况下，每个唯一的客户端组都会收到由群集配置的固定配额（以字节/秒为单位）。此配额是以每个经纪人为基础定义的。客户端被限制之前，每个客户端组可以发布/获取每个代理的最大X字节/秒。

请求率配额

请求率限额定义为客户端可以在请求处理程序的I / O线程和配额窗口内每个代理的网络线程上使用的时间百分比。n％的配额代表一个线程的n％，所以配额超出了（（num.io.threads + num.network.threads）* 100）％的总容量。每组客户可以使用总共百分比高达n％在被限制之前在配额窗口中跨越所有I / O和网络线程。由于为I / O和网络线程分配的线程数通常基于代理主机上可用的内核数，因此请求速率限额表示可由共享配额的每组客户端使用的CPU的总百分比。

强制

默认情况下，每个唯一的客户端组都会收到由群集配置的固定配额。此配额是以每个经纪人为基础定义的。每个客户可以在每个经纪人受到限制之前利用这个配额。我们认为，为每个代理定义这些配额比每个客户端具有固定的群集带宽要好得多，因为这需要一种机制来共享所有代理中的客户端配额使用。这可能比配额实施本身更难得到！

经纪人在检测到违反配额时会如何反应？在我们的解决方案中，代理不会返回错误，而是尝试减慢超出配额的客户端。它计算将有罪客户限制在其配额之下所需的延迟时间，并延迟当时的回应。这种方法使配额违反对客户端透明（客户端指标以外）。这也使他们不必执行任何特殊的退避和重试行为，这可能会变得棘手。事实上，糟糕的客户行为（无退避的重试）可能会加剧配额试图解决的问题。

字节率和线程利用率是在多个小窗口（例如每个窗口为1秒的30个窗口）上测量的，以便快速检测和纠正配额违规。通常，具有大的测量窗口（例如，每个30秒的10个窗口）导致大的突发流量，随后的长时间延迟，在用户体验方面不太好。

kafka官网翻译二：API使用，配置，设计