一：生产端
生产端的参数定义在类：org.apache.kafka.clients.consumer.ConsumerConfig。
1.1：bootstrap.servers：默认值：空
用于建设到 Kafka 群集的初始连贯的主机 / 端口对的列表。客户机将应用所有服务器而不仅仅应用这里配置的节点。因为这些服务器地址仅用于初始化连贯，并通过现有配置的来发现全副的 kafka 集群成员（集群随时会变动），所以此列表不须要蕴含残缺的集群地址（但尽量多配置几个，以避免配置的服务器宕机）
格局：host1:port1,host2:port2,...
1.2：client.dns.lookup：默认值：default
管制客户端如何应用 DNS 查找。如果配置为 use_all_dns_ips，则顺次连贯到每个返回的 IP 地址，直到胜利建设连贯。如果配置为 resolve_canonical_bootstrap_servers_only，则将每个疏导地址解析成一个 canonical 名称列表。
1.3：group.id：默认值：null
消费者所属的消费者组的惟一标识。上面 2 种状况下，group.id 必须要设置：(1)：基于 kafka 的 offset 管理策略。(2)：KafkaConsumer 应用 subscribe 接口订阅音讯。
1.4：group.instance.id：默认值：null
消费者实例 ID，只容许非空字符串。如果设置，则使用者将被视为动态成员，这意味着在任何时候消费者组中只容许有一个具备此 ID 的实例。如果不设置，消费者将作为动静成员退出群，这是传统行为。
1.5：session.timeout.ms：默认值：10000 毫秒
消费者组外面，检测消费者失败的会话超时工夫。消费者会固定周期发送心跳音讯到服务端，当服务端在指定工夫内没有收到心跳音讯，则认为消费者失落。这时候，服务端会从消费者组里踢出该节点，而后从新再均衡。须要留神的是：该值必须在 group.min.session.timeout.ms 和 group.max.session.timeout.ms 之间。
1.6：heartbeat.interval.ms：默认值：3000 毫秒
kafka 生产组外面冀望的心跳间隔时间。心跳是用来确保消费者会议放弃沉闷，并在新消费者退出或来到个人时促成再均衡。该值必须设置为低于 session.timeout.ms 的配置。但通常应设置为比这个值的三分之一还小。
1.7：partition.assignment.strategy：默认值：RangeAssignor.class
当应用组治理时，客户端将应用分区调配策略的类名来调配消费者实例之间的分区所有权。通过实现 org.apache.kafka.clients.consumer.ConsumerPartitionAssignor 接口，能够插入自定义调配策略。
1.8：metadata.max.age.ms：默认值：5601000 毫秒
强制刷新元数据的周期时间。即便没有任何分区领导层更改，也能够被动发现任何新的代理或分区。
1.9：enable.auto.commit：默认值：true
如果为 true，消费者的 offset 将在周期性的在后盾主动提交。
1.10：auto.commit.interval.ms：默认值：5000 毫秒
消费者主动提交 offset 的频率。当 enable.auto.commit 的值为 true 时无效。
1.11：client.id：默认值：””
发出请求时要传递给服务器的 id 字符串，这样做的目标是通过容许在服务器端申请日志记录中蕴含逻辑应用程序名称，从而可能跟踪 ip/ 端口以外的申请源。
1.12：client.rack：默认值：””
此客户端的机架标识符。这能够是任何字符串值，批示此客户端的物理地位。它与 broker 配置“broker.rack”绝对应
1.13：max.partition.fetch.bytes：默认值：110241024（1M）。
每个申请从服务器上每个分区返回的最大数据量。消费者批量从服务端获取数据，如果获取到的第一个非空的 partition 的数量大于该值，则依然会返回。服务器端最大的返回数据量由 message.max.bytes 配置决定（这个是服务端的配置）。或者通过 topic 的 max.message.bytes 配置设置。
1.14：send.buffer.bytes：默认值：128*1024
发送数据时要应用的 TCP 发送缓冲区的大小（SO_SNDBUF）。如果值为 -1，则应用 OS 默认值。
1.15：receive.buffer.bytes：默认值：64*1024
读取数据时要应用的 TCP 接收缓冲区（SO_RCVBUF）的大小。如果值为 -1，则应用 OS 默认值。
1.16：fetch.min.bytes：默认值：1
从服务器上获取申请返回的最小数据量。如果没有足够的数据可用，申请将期待大量数据积攒后再答复申请。默认设置为 1 字节意味着只有有一个字节的数据可用，或者提取申请在期待数据达到时超时，提取申请就会失去响应。将此值设置为大于 1 的值将导致服务器期待更大数量的数据累积，这会略微进步服务器吞吐量，但会减少一些提早。
1.17：fetch.max.bytes：默认值：5010241024（50M）
每个申请从服务器上返回的最大数据量。消费者批量从服务端获取数据，如果获取到的第一个非空的 partition 的数量大于该值，则依然会返回。服务器端最大的返回数据量由 message.max.bytes 配置决定（这个是服务端的配置）。或者通过 topic 的 max.message.bytes 配置设置。
1.18：fetch.max.wait.ms：默认值：500 毫秒。
如果没有足够的数据来立刻满足 fetch.min.bytes 给出的要求，则服务器在响应 fetch 申请之前将阻止的最长工夫。
1.19：reconnect.backoff.ms：默认值：50 毫秒
尝试从新连贯到给定主机之前期待的根本工夫量。这样能够防止在严密循环中反复连贯到主机。此回退实用于客户端到代理的所有连贯尝试。
1.20：reconnect.backoff.max.ms：默认值：1000 毫秒
从新连贯到反复连贯失败的代理时期待的最大工夫（毫秒）
1.21: retry.backoff.ms: 默认值值：100 毫秒
尝试重试对给定主题分区的失败申请之前期待的工夫量。这样能够防止在某些故障状况下以严密循环的形式反复发送申请。
1.22：auto.offset.reset：默认值：latest。可选值（”latest”, “earliest”, “none”）
如果 Kafka 中没有初始偏移量，或者服务器上不再存在以后偏移量（例如，因为该数据已被删除），该怎么办：
earliest：主动将偏移量重置为最早偏移量
latest：主动将偏移量重置为最新偏移量
none：消费者组没有找到地位偏移量，抛出异样
1.23：check.crcs：默认值：true
主动查看已耗费记录的 CRC32。这可确保不会产生对音讯的在线或磁盘损坏。此查看会减少一些开销，因而在寻求极其性能的状况下可能会禁用它。
1.24：metrics.sample.window.ms：默认值：30000 毫秒
计算度量样本的工夫窗口。
1.25：metrics.num.samples
为计算度量而保留的样本数。
1.26: metrics.recording.level: 默认值：INFO。可选值：DEBUG，INFO
计算最高纪录级别。
1.27：key.deserializer：默认值：
接口 org.apache.kafka.common.serialization.Deserializer 的实现类。对 KEY 进行反序列化。
1.28：value.deserializer：默认值：
接口 org.apache.kafka.common.serialization.Deserializer 的实现类。用以对 VALUE 值进行反序列化。
1.29：request.timeout.ms：默认值：30000 毫秒
配置管制客户端对发动的申请响应期待的最长工夫。如果在超时前没有收到响应，当重试次数没有用完之前，将发动重试，当重试次数用完之后，将失去失败。
1.30：default.api.timeout.ms：默认值：60000 毫秒
消费者 API 可能阻塞的默认超时工夫。没有设置 timeout 参数时，应用该默认值。
1.31：connections.max.idle.ms：默认值：9*60000 毫秒
配置连贯的最大闲暇工夫。超过这个工夫连贯将敞开。
1.32：interceptor.classes：默认值：空列表
接口 org.apache.kafka.clients.consumer.ConsumerInterceptor 的实现类列表。用以增加在消费者受到音讯之前的拦截器。
1.33：max.poll.records：默认值：500
单次 poll 申请获取的最大记录条数。
1.34：max.poll.interval.ms：默认值：300000 毫秒
应用消费者组治理时，调用 poll 命令的最大延迟时间。此值是消费者获取记录前的最大闲暇工夫。如果消费者在此超时工夫达到之前没有调用 poll 命令，则认为此消费者是失败的，此时会触发消费者组的再均衡，以便将此分区调配给其它的消费者。如果消费者的 group.instance.id 配置是非空的，那么达到此超时工夫，不会立即重新分配分区，此时消费者将进行发送心跳音讯，在达到 session.timeout.ms 配置的超时工夫后，分区才会被重新分配。此反映的是已敞开消费者的行为。
1.35：exclude.internal.topics：默认值：true
订阅模式的外部 topic 是否应该从订阅 topic 中排除
1.36：internal.leave.group.on.close：默认值：true
消费者敞开后，是否从消费者组里移除
1.37：isolation.level：默认值：READ_UNCOMMITTED，可选值：READ_COMMITTED，READ_UNCOMMITTED
管制如何读取事务性写入的音讯。如果配置的是 read_committed，那么消费者应用 poll 命令只能读取事务性提交的音讯。如果配置的是 read_uncommitted，那么将失去所以的音讯，甚至事务曾经中断。非事务性音讯在任何一种模式下都将无条件返回。
1.38：allow.auto.create.topics：默认值：true
在订阅或者调配 topic 时，是否容许在服务端主动创立 topic。同时，服务端的 auto.create.topics.enable 配置也必须为 true 能力主动创立。
1.39：security.providers：默认值：null
接口 org.apache.kafka.common.security.auth.SecurityProviderCreator 的实现类，用以实现平安算法。
1.40：security.protocol：默认值：PLAINTEXT
和服务端的通信协定。有效值是：Utils.join(SecurityProtocol.names(), “, “)
二：生产端
生产端的参数定义在类：org.apache.kafka.clients.producer.ProducerConfig
2.1：bootstrap.servers：默认值：空
用于建设到 Kafka 群集的初始连贯的主机 / 端口对的列表。客户机将应用所有服务器而不仅仅应用这里配置的节点。因为这些服务器地址仅用于初始化连贯，并通过现有配置的来发现全副的 kafka 集群成员（集群随时会变动），所以此列表不须要蕴含残缺的集群地址（但尽量多配置几个，以避免配置的服务器宕机）
格局：host1:port1,host2:port2,...
2.2：client.dns.lookup：默认值：default
管制客户端如何应用 DNS 查找。如果配置为 use_all_dns_ips，则顺次连贯到每个返回的 IP 地址，直到胜利建设连贯。如果配置为 resolve_canonical_bootstrap_servers_only，则将每个疏导地址解析成一个 canonical 名称列表。
2.3：buffer.memory：默认值：3210241024L
生产者能够用来缓冲期待发送到服务器的记录的总内存字节数。如果发送记录的速度比传输到服务端的速度快，那么生产端将被阻塞 MAX_BLOCK_MS_CONFIG 配置的工夫，而后会抛出异样。此设置应大抵与生产者将应用的总内存绝对应，但不是硬限度。因为不是所有生产者都应用的缓冲。
2.4：retries：默认值：Integer.MAX_VALUE。范畴：[0,Integer.MAX_VALUE]
设置一个大于零的值将导致客户端从新发送任何呈现暂时性谬误而发送失败的记录。此重试与客户端在收到谬误时从新发送记录没有区别。如果 MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION 设置的不是 1，那么重试可能扭转音讯达到 partition 的程序。比方第一个音讯失败了重试，第二个音讯胜利，那么第二个音讯可能先于第一个达到 partition。在配置了 DELIVERY_TIMEOUT_MS_CONFIG 的超时工夫后，即便重试次数没有应用完，然而超时工夫已到，那么也会失败。同城状况下，能够不设置此属性，而应用 DELIVERY_TIMEOUT_MS_CONFIG 来管制。
2.5：acks：默认值：”1″，可选值：”all”, “-1”, “0”, “1”
Leader 收到的应答数以确定生产者申请是否解决实现。
如果设置为 0，生产者将不会期待服务端的应答，音讯将立刻增加到套接字缓冲区并被视为已发送。在这样的状况下，不能保障音讯已发送到服务端，而且 retries 配置将不会失效。
如果设置为 1, 音讯被发送到 Leader，并写入 Leader 的 log 后，并不会期待 follow 的应答就间接响应。在这样的状况下，Leader 能够确定收到音讯，然而 Follow 可能会存在音讯失落。
如果设置为 all，那 Leader 会期待所有的 follow 都应答后再响应。这强力保障了音讯不会失落。
如果设置为 -1，成果和设置为 all 一样。
2.6：compression.type：默认值：none
生产者生成的所有数据的压缩类型。默认值为 none，示意无压缩。有效值为：none，gzip，snappy，lz4，zstd。压缩是对整批数据的压缩，所以批处理的成果也会影响压缩比。
2.7：batch.size：默认值：16384
每当多个音讯发送到同一个 partition，生产者将尝试将记录批处理到一起，以缩小申请。这有助于进步客户机和服务器的性能。此配置管制以字节为单位的默认批处理大小。不会尝试批处理大于此大小的记录。发送到代理的申请将蕴含多个批处理，每个分区一个批处理。比拟小的 batch.size 并不是很通用，并可能升高吞吐量。一个十分大的 batch.size 可能会应用内存有点节约，因为咱们总是调配一个指定批量大小的缓冲区，以预期其余记录。
2.8: linger.ms: 默认值：0
生产者将在申请传输之间达到的所有记录组合到一个独自的批处理申请中。通常状况下，只有当记录达到的速度比发送的速度快时，才会产生这种状况。但在某些状况下，客户可能心愿即便在适合负载下也要缩小申请数。这个配置设置的是一个提早。这样生产者不用立马发送音讯，而是期待配置的工夫，以便进行批量发送音讯，这个相似于 TCP 中的 Nagle 算法。当咱们配置了 BATCH_SIZE_CONFIG 后，linger.ms 是期待的下限，即便音讯字节数没有达到配置的值。如果 LINGER_MS_CONFIG 配置为 0，示意不期待。
2.9：delivery.timeout.ms：默认值：120*1000 毫秒
调用 send() 办法后，报告胜利或者失败的工夫下限。这个配置限度了音讯提早发送，期待服务端确认，失败重试的最大工夫下限。当遇到不可复原的谬误，重试次数已用尽，当工夫没有达到这个上限值，也会提前返回后果。此值应该不小于 REQUEST_TIMEOUT_MS_CONFIG 和 LINGER_MS_CONFIG 之和的值。
2.10：client.id：默认值：””
发出请求时要传递给服务器的 id 字符串。这样做的目标是通过容许在服务器端申请日志记录中蕴含逻辑应用程序名称，从而可能跟踪 ip/ 端口以外的申请源。
2.11：send.buffer.bytes：默认值：128*1024
发送数据时要应用的 TCP 发送缓冲区（SO_SNDBUF）的大小。如果值为 -1，则应用 OS 默认值。
2.12：receive.buffer.bytes：默认值：32*1024
在读取数据时要应用的 TCP 接收缓冲区（SO_RCVBUF）的大小。如果值为 -1，则应用 OS 默认值。
2.13：max.request.size：默认值：1024*1024
申请的最大大小（字节）。当生产者批量发送音讯时候，该设置限度着最大值，免得发送一个超大的申请。留神服务端也有一个申请的最大值，可能和这个值不一样。
2.14：reconnect.backoff.ms：默认值：50L
尝试从新连贯到给定主机之前期待的根本工夫量。这样能够防止在严密循环中反复连贯到主机。
2.15：reconnect.backoff.max.ms：默认值：1000L
从新连贯到服务器的最大等待时间。如果提供的话，每台主机的重连将随着每个间断的连贯失败而成倍增加，直到这个最大值。
2.16：retry.backoff.ms：默认值：100L
尝试重试对给定主题分区的失败申请之前期待的工夫量。这样能够防止在某些故障状况下以严密循环的形式反复发送申请。
2.17：max.block.ms：默认值：60 * 1000
管制 KafkaProducer.send() 和 KafkaProducer.partitionsFor() 命令的阻塞工夫。因为缓冲区已满或元数据不可用，这些办法可能被阻止。用户提供的序列化程序或分区程序中的阻塞将不计入此超时。
2.18：request.timeout.ms：默认值：30*1000
配置管制客户端期待申请的响应的最大工夫。如果在超时工夫达到之前依然没有失去响应，那么将重试或者失去失败。此配置的值应该大于 replica.lag.time.max.ms 的值，以缩小因为不必要的生产者重试而导致音讯反复的可能性。
2.19：metadata.max.age.ms：默认值：5601000
以毫秒为单位的一段时间，在这段时间之后，咱们强制刷新元数据，即便咱们没有看到任何分区领导层更改，也能够被动发现任何新的代理或分区。
2.20：metrics.sample.window.ms：默认值：30000
计算度量样本的工夫窗口。
2.21：metrics.num.samples：默认值：2
为计算度量而保留的样本数。
2.22：metrics.recording.level：默认值：INFO。可选值：INFO，DEBUG
度量的最高记录级别。
2.23：metric.reporters：默认值：空
用作度量报告器的类的列表。是 org.apache.kafka.common.metrics.MetricsReporter 接口的实现类。JmxReporter 总是蕴含在注册 JMX 统计信息中。
2.24：max.in.flight.requests.per.connection：默认值：5
在阻塞之前，客户端将在单个连贯上发送的最大未确认申请数。请留神，如果将此设置设置为大于 1 并且存在失败的发送，则存在因为重试而导致音讯从新排序的危险。
2.25：key.serializer：默认值：无
接口 org.apache.kafka.common.serialization.Serializer 的实现类，用以对 KEY 进行序列化。
2.26：value.serializer：默认值：无
接口 org.apache.kafka.common.serialization.Serializer 的实现类，用以对 value 进行序列化。
2.27：connections.max.idle.ms：默认值：9601000
在此配置指定的毫秒数之后敞开闲暇连贯。
2.28：partitioner.class：默认值：无
接口 org.apache.kafka.clients.producer.Partitioner 的实现类，用以自定义分片算法。
2.29：interceptor.classes：默认值：空
接口 org.apache.kafka.clients.producer.ProducerInterceptor 的实现类的拦截器列表。容许音讯在发送到 Kafka 集群之前，对音讯进行拦挡。默认状况，是没有拦截器的。
2.30：security.protocol：默认值：PLAINTEXT
和服务器的通信协定。可能的值是：Utils.join(SecurityProtocol.names(), “, “)
2.31：security.providers：默认值：空
接口 org.apache.kafka.common.security.auth.SecurityProviderCreator 的实现类列表，用以实现平安算法。
2.32：enable.idempotence：默认值：false
当设置为“true”时，生产者将确保流中只写入每条音讯的一个正本。如果“false”，则因为服务端失败等起因导致的生产者重试可能会在流中写入重试音讯的正本。须要留神的是，如果设置为 true，那么配置 MAX_IN_FLIGHT_REQUESTS_PER_CONNECTION 的值必须小于等于 5，RETRIES_CONFIG 配置必须大于 0，ACKS_CONFIG 配置必须是 all。如果用户未明确设置这些值，则将抉择适合的值。如果设置了不兼容的值，将抛出 ConfigException。
2.33：transaction.timeout.ms：默认值：60000
事务协调器在被动停止正在进行的事务之前期待生产者更新事务状态的最长工夫（毫秒）。如果此值大于代理中的 transaction.max.timeout.ms 设置，求将失败，并呈现 InvalidTransactionTimeout 谬误。
2.34：transactional.id：默认值：无
用于事务传递的 TransactionalId。这反对跨多个生产者会话的可靠性语义，因为它容许客户机保障在启动任何新事务之前，应用雷同 TransactionalId 的事务曾经实现。如果未提供 TransactionalId，则生产者仅限于幂等传递。请留神，如果配置了 TransactionalId，那么 enable.idempotence 的配置必须是 true。默认值为 null，这意味着不能应用事务。