3.3 Producer Configs
key.serializer
用于实现 org.apache.kafka.common.serialization.Serializer 接口的key的序列化器类。
Type: class Default: Valid Values: Importance: high
value.serializer
用于实现 org.apache.kafka.common.serialization.Serializer 接口的value的序列化器类。
Type: class Default: Valid Values: Importance: high
bootstrap.servers
用于建立与Kafka集群的初始连接的主机/端口对列表。客户端将使用所有服务器,无论这里指定了哪些服务器用于引导 - 这个列表只影响用于发现完整服务器集合的初始主机。这个列表应该是host1:port1,host2:port2,…的形式。由于这些服务器只是用于建立初始连接,以发现可能动态变化的完整集群成员,所以这个列表不需要包含完整的服务器集合(不过,你可能需要多于一个,以防某个服务器宕机)。
Type: list Default: "" Valid Values: non-null string Importance: high
buffer.memory
生产者可以用来缓存等待发送到服务器的记录的内存总字节数。如果记录发送的速度快于服务器的处理速度,生产者将会阻塞,直到max.block.ms时间到达后抛出异常。
这个设置应该大致对应于生产者使用的总内存,但不是一个严格的限制,因为生产者使用的内存并不都用于缓存。一些额外的内存将用于压缩(如果启用了压缩)以及维护在途请求。
Type: long Default: 33554432(32M) Valid Values: [0,...] Importance: high
compression.type
生产者生成的所有数据的压缩类型。默认值是none(即不压缩)。有效值是none, gzip, snappy, lz4, 或 zstd。压缩是对完整的数据批次进行的,所以批次的效率也会影响压缩比(批次越多,压缩越好)。
Type: string Default: none Valid Values: [none, gzip, snappy, lz4, zstd] Importance: high
retries
如果设置一个大于零的值,客户端将重新发送任何因可能是暂时性的错误而发送失败的记录。请注意,这种重试与客户端在收到错误后重新发送记录没有什么不同。如果在成功确认之前,由delivery.timeout.ms配置的超时时间先到期,那么在重试次数耗尽之前,生产请求将失败。用户通常应该更倾向于不设置这个配置,而是使用delivery.timeout.ms来控制重试行为。
启用幂等性要求这个配置值大于0。如果设置了冲突的配置,并且没有明确启用幂等性,那么幂等性将被禁用。
在设置enable.idempotence为false和max.in.flight.requests.per.connection大于1的同时允许重试,可能会改变记录的顺序,因为如果两个批次被发送到同一个分区,第一个失败并被重试,但第二个成功,那么第二个批次中的记录可能会先出现。
Type: int Default: 2147483647 Valid Values: [0,...,2147483647] Importance: high
ssl.key.password
密钥存储文件中私钥的密码或“ssl.keystore.key”中指定的 PEM 密钥的密码。
Type: password Default: null Valid Values: Importance: high
batch.size
生产者会尝试将多个记录批量发送到同一个分区,以减少请求的次数。这样可以提高客户端和服务器的性能。这个配置控制了默认的批量大小,单位是字节。
不会尝试将大于这个大小的记录进行批量发送。
发送到代理的请求将包含多个批次,每个分区有可发送的数据对应一个批次。
批量大小小会使批量发送变得不常见,可能降低吞吐量(批量大小为零将完全禁用批量发送)。批量大小大可能会造成内存的浪费,因为我们总是会分配一个指定批量大小的缓冲区,以期待更多的记录。
注意:这个设置给出了要发送的批量大小的上限。如果我们在这个分区累积的字节数少于这个值,我们会在linger.ms时间内等待更多的记录出现。这个linger.ms设置默认为0,这意味着即使累积的批量大小低于这个batch.size设置,我们也会立即发送出一条记录。
Type: int Default: 16384(16k) Valid Values: [0,...] Importance: medium
linger.ms
生产者会将在请求传输之间到达的任何记录组合成一个批量请求。通常这只在负载较高时发生,当记录到达的速度快于发送出去的速度时。但是在某些情况下,客户端可能希望在负载适中时也减少请求的次数。这个设置通过添加一小段人为的延迟来实现这一点,也就是说,生产者不会立即发送出一条记录,而是会等待给定的延迟时间,以便让其他记录也能被发送,从而使发送能够被批量进行。这可以类比为TCP中的Nagle算法。这个设置给出了批量延迟的上限:一旦我们得到了一个分区的batch.size值的记录,它将立即被发送,不管这个设置如何,但是如果我们在这个分区累积的字节数少于这个值,我们会在指定的时间内“逗留”,等待更多的记录出现。这个设置默认为0(即没有延迟)。例如,设置linger.ms=5,将会减少发送的请求次数,但是会增加最多5ms的延迟,对于在没有负载时发送的记录。
Type: long Default: 0 Valid Values: [0,...] Importance: medium
max.request.size
请求的最大字节数。这个设置将限制生产者在单个请求中发送的记录批次的数量,以避免发送过大的请求。这也相当于对最大未压缩记录批次大小的一个限制。请注意,服务器对记录批次大小(如果启用了压缩,就是压缩后的大小)也有自己的限制,这可能与这个设置不同。
Type: int Default: 1048576 Valid Values: [0,...] Importance: medium
partitioner.class
决定将记录发送到哪个分区的策略。可选项有:
如果不设置,就使用默认的分区逻辑。这种策略会将记录发送到一个分区,直到该分区产生至少batch.size字节的数据。它的工作原理是:
如果没有指定分区,但是有键存在,就根据键的哈希值选择一个分区。
如果没有分区或键存在,就选择一个粘性分区,当该分区产生至少batch.size字节的数据时,分区会改变。
Type: class Default: null Valid Values: Importance: medium
partitioner.ignore.keys
如果设置为’true’,生产者不会使用记录key来选择分区。如果设置为’false’,当有键存在时,生产者会根据键的哈希值选择一个分区。注意:如果使用了自定义分区器,这个设置没有效果。
Type: boolean Default: false Valid Values: Importance: medium
acks
生产者在认为一个请求完成之前,需要从领导者那里收到的确认的数量。这个控制了发送的记录的持久性。以下设置是允许的:
acks=0 如果设置为零,那么生产者不会等待服务器的任何确认。记录将立即被添加到套接字缓冲区,并被认为已发送。在这种情况下,不能保证服务器已经收到了记录,而且retries配置也不会生效(因为客户端通常不知道任何失败)。每条记录返回的偏移量将始终设置为-1。 acks=1 这将意味着领导者将记录写入其本地日志,但不会等待所有跟随者的完全确认。在这种情况下,如果领导者在确认记录后但在跟随者复制之前立即失败,那么记录将丢失。 acks=all 这意味着领导者将等待完整的同步副本集来确认记录。这保证了只要至少有一个同步副本仍然存活,记录就不会丢失。这是最强的可用保证。这相当于acks=-1的设置。 注意,启用幂等性需要这个配置值为’all’。如果设置了冲突的配置,并且没有明确启用幂等性,那么幂等性将被禁用。
Type: string Default: all Valid Values: [all, -1, 0, 1] Importance: low
enable.idempotence
Type: boolean Default: true Valid Values: Importance: low
max.in.flight.requests.per.connection
如果设置为’true’,生产者将确保每条消息在流中只写入一次。如果设置为’false’,由于代理失败等原因导致的生产者重试,可能会在流中写入重试消息的重复副本。注意,启用幂等性要求max.in.flight.requests.per.connection小于或等于5(对于任何允许的值,保留消息顺序),retries大于0,而且acks必须为’all’。
如果没有设置冲突的配置,幂等性默认启用。如果设置了冲突的配置,并且没有明确启用幂等性,那么幂等性将被禁用。如果明确启用了幂等性,并且设置了冲突的配置,那么将抛出ConfigException异常。
Type: int Default: 5 Valid Values: [1,...] Importance: low