一：消费端
消费端的参数定义在类：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：默认值：5*60*1000毫秒
强制刷新元数据的周期时间。即使没有任何分区领导层更改，也可以主动发现任何新的代理或分区。
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：默认值：1*1024*1024 （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：默认值：50*1024*1024（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： 默认值：32*1024*1024L
生产者可以用来缓冲等待发送到服务器的记录的总内存字节数。如果发送记录的速度比传输到服务端的速度快，那么生产端将被阻塞 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： 默认值：5*60*1000
以毫秒为单位的一段时间，在这段时间之后，我们强制刷新元数据，即使我们没有看到任何分区领导层更改，也可以主动发现任何新的代理或分区。
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： 默认值：9*60*1000
在此配置指定的毫秒数之后关闭空闲连接。
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，这意味着不能使用事务。