Applicaton.yml 中 Kafka 重要性较高的 Producer 和 Consuemr 配置

bootstrap-servers

broker 结点，格式：ip:port，多个节点之间用逗号分开

producer

retries

设置大于零的值将导致客户端重发发送失败的记录，这些记录可能存在短暂错误

请注意，此重试与客户端在收到错误后重新发送记录没有什么不同

在不将 max.in.flight.requests.per.connection 设置为 1 的情况下允许重试可能会改变记录的顺序

因为如果将两个批次发送到同一个分区，并且第一个批次失败并被重试，但第二个批次成功，那么在第二批中的记录可能更先出现

另外请注意，如果在成功确认之前 delivery.timeout.ms 配置的超时时间到了，而且重试次数已经耗尽，生产请求将失败

用户通常应该更喜欢不设置此配置，而是使用 delivery.timeout.ms 来控制重试行为

delivery.timeout.ms

调用 send() 返回后报告成功或失败的时间上限。这限制了记录在发送之前将被延迟的总时间：等待 broker 确认的时间（如果需要）以及可重试发送失败所允许的时间

如果遇到不可恢复的错误，重试已用尽或者记录被添加到到达更早交付的到期期限的批次中，生产者可能会在到此配置时间之前报告发送记录失败

此配置的值应大于等于 request.timeout.ms 和 linger.ms 的数值总和

linger.ms

生产者将在两个请求传输之间到达的任何记录组合成一个批处理请求

通常，这种合并操作仅在记录到达后被发送前，batch size 负载不满时发生

但是在某些情况下，即使在中等负载下，客户端也可能希望减少请求的数量

此设置通过添加少量人为延迟来实现这一点——也就是说，生产者不会立即发送记录，而是等待给定的延迟以允许发送其他记录，以便可以将发送一起批处理

这可以被认为类似于 TCP 中的 Nagle 算法。这个设置给出了批处理延迟的上限：一旦我们得到一个分区的 batch.size 值的记录，不管这个设置如何，它都会立即发送

但是如果我们为这个分区积累的字节数少于这个数量，我们将' linger' 指定时间等待更多记录出现

此设置默认为 0（即无延迟）。例如，设置 linger.ms=5 会产生减少发送请求数量的效果，但会给在没有负载的情况下发送的记录增加最多 5ms 的延迟

max.block.ms

配置控制 KafkaProducer.send() 和 KafkaProducer.partitionsFor() 的阻塞时长

这些方法可能因为缓冲区已满或元数据不可用而被阻塞。用户提供的序列化程序或分区程序中的阻塞将不计入此超时

默认时长 1 分钟

max.request.size

请求的最大大小（以字节为单位），此设置将限制生产者在单个请求中发送的记录批次数，以避免发送大量请求

这实际上也是最大未压缩记录批量大小的上限，请注意，服务器对记录批量大小有自己的上限（如果启用压缩，则在压缩之后），这可能与此不同

receive.buffer.bytes

读取数据时使用的 TCP 接收缓冲区 (SO_RCVBUF) 的大小。 如果值为 -1，将使用操作系统默认值

request.timeout.ms

配置客户端等待请求响应的最长时间。 如果在超时之前没有收到响应客户端将在必要时重新发送请求，或者如果重试次数用尽，则请求失败

这应该大于replica.lag.time.max.ms（broker 配置），以减少由于不必要的生产者重试而导致消息重复的可能性

send.buffer.bytes

发送数据时使用的 TCP 发送缓冲区 (SO_SNDBUF) 的大小，如果值为 -1，将使用操作系统默认值

enable.idempotence

当设置为“true”时，生产者将确保每条消息的一个副本被写入流中。 如果为“false”，生产者由于 broker 失败等原因重试，可能会在流中写入重试消息的副本

请注意，启用幂等性要求 max.in.flight.requests.per.connection 小于等于 5，retries 大于 0，并且 acks 必须为 all

如果用户没有明确设置这些值，则将选择合适的值。 如果设置了不兼容的值，则会抛出 ConfigException

interceptor.classes

用作拦截器的类列表。 实现 org.apache.kafka.clients.producer.ProducerInterceptor 接口允许您在生产者收到的记录发布到 Kafka 集群之前拦截（并可能改变）它们

默认情况下，没有拦截器。业务数据提前经过过滤再传递到中间件

max.in.flight.requests.per.connection

客户端在阻塞之前将在单个连接上发送的未被确认请求的最大数量。 请注意，如果此设置设置为大于 1 并且发送失败，则存在由于重试（即启用重试）而导致消息重新排序的风险

metadata.max.age.ms

即使没有看到任何分区领导层更改以主动发现任何新 broker 或 partition，强制刷新元数据的时间段（以毫秒为单位）

reconnect.backoff.max.ms

重新连接到反复连接失败的代理时等待的最长时间（以毫秒为单位）

如果提供，每台主机的退避将在每次连续连接失败时呈指数增长，直至达到此最大值。 在计算回退增加后，添加 20% 的随机抖动以避免连接风暴

reconnect.backoff.ms

在尝试重新连接到给定主机之前等待的基本时间量，这避免了在紧密循环中重复连接到主机。 此退避适用于客户端到代理的所有连接尝试

retry.backoff.ms

在尝试重试对给定主题分区的失败请求之前等待的时间量，这避免了在某些故障情况下在紧密循环中重复发送请求。

batch-size

每当多个记录被发送到同一个分区时，生产者将尝试将多个记录放一起批量处理，减少请求的数量

这有助于客户端和服务器的性能。 此配置控制默认批量大小（以字节为单位）

不会尝试批量处理大于此数量值的记录

发送到 broker 的请求将包含多个批次，每个分区都有可发送的数据

• 小批量将使批处理不太常规，并且可能会降低吞吐量（批量大小为零将完全禁用批处理）
• 一个非常大的批量大小可能会更浪费内存，因为我们总是会分配指定 batch size + 额外预估的记录量大小

buffer-memory

生产者可用于缓存等待被发送到服务器的记录的内存总字节数。 如果记录的发送出去的速度快于被传递到服务器的速度，则生产者将阻塞 max.block.ms 之后将抛出异常。

此设置应大致对应于生产者将使用的总内存，但不是硬性限制，因为并非生产者使用的所有内存都用于缓冲。 一些额外的内存将用于压缩（如果启用压缩）以及维护正在进行的请求。

与 batch-size 的区别

batch.size Kafka 生产者尝试将发送的消息收集到批次以提高吞吐量。 使用 Java 客户端，您可以使用 batch.size 控制每个消息批次的最大大小，以字节为单位

buffer.memory 使用 buffer.memory 限制总内存，Java 客户端可用于收集未发送的消息。

当这达到限制，生产者将阻止额外的发送，直到引发异常之前的这段时间作为 max.block.ms  

connections.max.idle.ms

在此配置指定的毫秒数后关闭空闲连接

compression-type

推荐使用 lz4，lz4 压缩对象是文件，而且适用于频繁压缩，快速解压的应用场景

key-serializer 和 value-serializer

序列化方式，多采用 org.apache.kafka.common.serialization.StringSerializer

acks 

发送消息确认模式

• 参数设置成 0

kafkaProducer在客户端，只要把消息发送出去，不管那条数据是否在 broker 落盘，直接认为这个消息发送成功

如果采用这种设置，可能会出现消息丢失，比如发送出去的消息还在半路，结果目标 Broker 直接挂了，客户端依旧认为消息发送成功了，此时就会导致这条消息就丢失

• 参数设置成 1

只要 Partition Leader 接收到消息并写入本地磁盘，不管其他的Follower有没有同步这条消息

这种设置其实是kafka默认的设置方式

如果采用这种设置，可能会出现消息丢失，比如在 Partition Leader 接收到消息后，Follower 还没来得及同步过去，结果 Leader 所在的 broker 宕机了，此时也会导致这条消息丢失

什么是 ISR

In-Sync Replicas，同步中的副本，是一个列表，里面是与 Leader 数据一致的副本

确定一个副本在 ISR 列表中，有 1 个判断条件 -- 副本和 leader 的交互时间差

如果大于某个时间差，就认定这个副本严重滞后，把此副本从 ISR 中剔除，此时间差根据配置参数 replica.lag.time.max.ms=10000 决定 单位ms

• 参数设置成 -1，也就是 all

Partition Leader 接收到消息之后，ISR 列表里跟 Leader 保持同步的 Follower 实现消息同步后，才认为这条消息是写入成功

如果采用这种设置，可能会出现消息丢失，比如 Partition Leader 刚接收到消息，但 Follower 没有收到消息，此时 Leader 宕机了，客户端会重试再次发送消息过去

若此时 Partition 2 的 Follower 变成 Leader了，此时 ISR 列表里只有最新的 Follower 转变成 Leader，那么只要这个新的 Leader 接收消息就算成功

acks=all 就代表数据一定不会丢失了吗，如果只有一个 broker，partition 本身就一个副本，那这个 leader 宕机数据自然会丢失

与 acks=-1 配合的 borker 配置

min.insync.replicas

当生产者将确认设置为“all”（或“-1”）时，min.insync.replicas 指定必须确认写入才能被视为成功的最小副本数

如果无法满足此最小值，则生产者将引发异常（NotEnoughReplicas 或 NotEnoughReplicasAfterAppend）

当一起使用时，min.insync.replicas 和 acks 允许您强制执行更大的持久性保证。

一个典型的场景是创建一个复制因子为 3 的主题，将 min.insync.replicas 设置为 2，并使用“all”的 acks 生成。 如果大多数副本没有收到写入，这将确保生产者引发异常

 

与 acks=-1 配合的 broker 配置

default.replication.factor

自动创建主题的默认复制因子

Consumer

fetch.min.bytes

服务器应为获取请求返回的最小数据量。 如果可用数据不足，则请求将在响应请求之前等待累积那么多数据

1 字节的默认设置意味着只要有一个字节的数据可用或获取请求超时，响应获取请求

将此设置为大于 1 的值将导致服务器等待大量数据累积，以一些额外的延迟为代价提高服务器吞吐量。

group.id（订阅模式下需要）

标识此消费者所属的消费者组的唯一字符串。 如果消费者使用 subscribe(topic) 或基于 Kafka 的偏移管理策略使用组管理功能，则需要此属性。

heartbeat.interval.ms

使用 Kafka 的组管理设施时，与消费者协调器之间的心跳之间的预期时间。 心跳用于确保消费者的会话保持活跃，并在新消费者加入或离开组时促进重新平衡

该值必须设置为低于 session.timeout.ms，但通常应设置为不高于该值的 1/3，它可以调整得更低，以控制正常重新平衡的预期时间

max.partition.fetch.bytes

服务器返回的每个分区的最大数据量， 记录由消费者分批获取

如果 fetch 的第一个非空分区中的第一个记录批大于此限制，则该批仍将返回以确保消费者可以进行

broker 接受的最大记录批量大小通过 message.max.bytes（broker 配置）或 max.message.bytes（topic 配置）定义

session.timeout.ms

使用 Kafka 的组管理工具时用于检测客户端故障的超时。 客户端定期发送心跳以向代理指示其活跃性

如果在此会话超时到期之前 broker 未收到任何心跳，则 broker 将从组中删除此客户端并启动重新平衡

请注意，该值必须在代理配置中 group.min.session.timeout.ms 和 group.max.session.timeout.ms 配置的允许范围内

allow.auto.create.topics

订阅或分配主题时，允许在 broker 上自动创建主题

仅当 broker 允许使用 `auto.create.topics.enable` broker 配置时，才会自动创建订阅的主题。 使用早于 0.11.0 的 boker 时，此配置必须设置为 `false`

auto.offset.reset

如果 Kafka 中没有初始偏移量或服务器上不再存在当前偏移量（例如，因为该数据已被删除），该怎么办：

• earliest：自动将偏移量重置为最早的偏移量
• latest：  自动将偏移量重置为最晚的偏移量
• none：   如果没有为消费者组找到先前的偏移量，则向消费者抛出异常
• anything else：向消费者抛出异常

connections.max.idle.ms

在此配置指定的毫秒数后关闭空闲连接

default.api.timeout.ms

指定客户端 API 的超时时间（以毫秒为单位），此配置用作所有未指定超时参数的客户端操作的默认超时

enable.auto.commit

如果为 true，消费者的偏移量将在后台定期提交

exclude.internal.topics

是否应从订阅中排除与订阅模式匹配的内部主题，始终可以显式订阅内部主题

fetch.max.bytes

服务器应为获取请求返回的最大数据量。 记录由消费者分批获取，如果获取的第一个非空分区的第一个记录批大于该值，仍然会返回记录批，以确保消费者可以进行，这不是绝对最大值

broker 接受的最大记录批量大小通过 message.max.bytes（broker 配置）或 max.message.bytes（toptic 配置）定义。 请注意，消费者并行执行多个提取

group.instance.id

最终用户提供的消费者实例的唯一标识符。 只允许非空字符串

如果设置，消费者将被视为静态成员，这意味着在任何时候都只允许具有此 ID 的一个实例在消费者组

这可以与更大的会话超时结合使用，以避免由于暂时不可用（例如进程重新启动）导致的组重新平衡

如果不设置，消费者将作为动态成员加入群组，这是传统的行为

isolation.level

控制如何读取以事务方式写入的消息

• 如果设置为 read_committed，consumer.poll() 将只返回已提交的事务消息
• 如果设置为 read_uncommitted（默认值），consumer.poll() 将返回所有消息，甚至是已中止的事务消息

在二者任一模式下都将无条件返回非事务性消息

消息将始终按偏移顺序返回，因此，在 read_committed 模式下，consumer.poll() 将只返回最后一个稳定偏移量 (LSO) 的消息，该偏移量小于第一个打开事务的偏移量

特别是在属于正在进行的交易的消息之后出现的任何消息都将被保留，直到相关交易完成

因此，当存在正在进行的事务时，read_committed 消费者将无法读取到高水位线，此外，在 read_committed 中， seekToEnd 方法将返回 LSO

max.poll.interval.ms

使用消费者组管理时调用 poll() 之间的最大延迟

这为消费者在获取更多记录之前可以空闲的时间量设置了上限，如果在此超时到期之前未调用 poll()，则认为消费者失败，组将重新平衡，以便将分区重新分配给另一个成员

静态消费者的情形

• 对于使用达到此超时的非空 group.instance.id 的消费者，不会立即重新分配分区
• 相反，消费者将停止发送心跳，并且分区将在 session.timeout.ms 到期后重新分配

max.poll.records

在一次 poll() 调用中返回的最大记录数

partition.assignment.strategy

支持的分区分配策略的类名称或类类型列表，当使用组管理时，客户端将使用这些策略在消费者实例之间分配分区所有权

除了下面指定的默认类 org.apache.kafka.clients.consumer.RangeAssignor 之外，还可以使用 org.apache.kafka.clients.consumer.RoundRobinAssignor 类将分区循环分配给消费者（轮询）

实现 org.apache.kafka.clients.consumer.ConsumerPartitionAssignor 接口允许您插入自定义分配策略

auto.commit.interval.ms

如果 enable.auto.commit 设置为 true，消费者偏移量自动提交到 Kafka 的频率（以毫秒为单位）