Kafka生产者配置

孙花菜

已于 2023-11-30 22:53:26 修改

阅读量66

点赞数

分类专栏： kafka 文章标签： kafka 分布式 java

于 2023-11-29 20:47:40 首次发布

本文链接：https://blog.csdn.net/u011345506/article/details/134698824

版权

kafka 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

官网地址

kafka官网

配置代码示例

package test.config;

import jakarta.annotation.Resource;
import org.apache.kafka.clients.producer.KafkaProducer;
import org.apache.kafka.clients.producer.ProducerConfig;
import org.springframework.stereotype.Component;

import java.util.HashMap;
import java.util.Map;

@Component
public class KafkaProducerConfig{

    @Resource
    private KafkaPropertiesConfig propertiesConfig;

    public Map<String, Object> producerConfigs() {
        // 创建Kafka的配置信息
        Map<String, Object> properties = new HashMap<>(16);
        // 指定broker，会自动从broker中获取元数据信息
        properties.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, propertiesConfig.getBootstrapServers());
        // 执行ack应答机制
        properties.put(ProducerConfig.ACKS_CONFIG, propertiesConfig.getAcks());
        // 指定重试次数
        properties.put(ProducerConfig.RETRIES_CONFIG, propertiesConfig.getRetries());
        // 指定批处理的字节数
        properties.put(ProducerConfig.BATCH_SIZE_CONFIG, propertiesConfig.getBatchSize());
        // 等待时间，如果批次未满 间隔一定时间发出去
        properties.put(ProducerConfig.LINGER_MS_CONFIG, propertiesConfig.getLingerMs());
        // RecordAccumulator缓冲区大小
        properties.put(ProducerConfig.BUFFER_MEMORY_CONFIG, propertiesConfig.getBufferMemory());
        // 指定key序列化器
        properties.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, propertiesConfig.getKeySerializer());
        // 指定value序列化器
        properties.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, propertiesConfig.getValueSerializer());
        // 开启幂等性
        properties.put(ProducerConfig.ENABLE_IDEMPOTENCE_CONFIG, propertiesConfig.getIdempotence());
        // 生产端能够发送的最大消息大小，默认值为1048576字节(1M)
        properties.put(ProducerConfig.MAX_REQUEST_SIZE_CONFIG, propertiesConfig.getMaxRequestSize());
        // os  page cache 中压缩格式
        properties.put(ProducerConfig.COMPRESSION_TYPE_CONFIG, propertiesConfig.getCompressionType());
        // 控制客户端等待请求响应的最长时间。
        // 如果超时之前仍未收到响应，则客户端将在必要时重新发送请求，如果重试次数（retries）已用尽，则请求失败。
        // 此值应大于replica.lag.time.max.ms（broker配置），以减少由于不必要的生产者重试而导致消息重复的可能性。
        properties.put(ProducerConfig.REQUEST_TIMEOUT_MS_CONFIG, propertiesConfig.getRequestTimeoutMs());
        // 指定控制KafkaProducer.send()方法和KafkaProducer.partitionsFor()方法的阻塞时间，
        // 这些方法可以由于缓冲区已满或元数据不可用而被阻塞，用户提供的序列化器或分区器中的阻塞将不计入此超时时间。
        properties.put(ProducerConfig.MAX_BLOCK_MS_CONFIG, propertiesConfig.getMaxBlockMs());

        return properties;
    }

    public KafkaProducer<String, Object> createKafkaProducer() {
        return new KafkaProducer<>(producerConfigs());
    }
}

acks

指定必须要有多少个分区副本收到消息，生产者才认为消息写入是成功的。本参数对消息丢失的可能性有重要影响。
string类型，默认值为all，可选值有：

0：acks = 0 表示生产者在成功写入消息之前不会等待任何来自服务器的响应。消息将立即添加到缓冲区中，并被视为已发送。
在这种情况下，无法保证服务器已收到记录，并且重试配置不会生效（因为客户端通常不会知道任何失败）。
缺点是，如果出现了任何问题，导致服务器没有收到消息，那么生产者无从得知消息是否到达了服务器，消息也就丢失了。
优点是，因为生产者不需要等待服务器的响应，所以它可以以网络能够支持的最大速度发送消息，从而达到很高的吞吐量。
1：acks = 1 表示只需要集群的leader节点收到消息，生产者就会收到一个来自服务器的成功响应。如果消息无法到达leader节点（例如leader节点崩溃，新的leader还没有选举出来），生产者会受到一个错误响应，为了避免数据丢失，生产者会重发消息。但是，如果一个没有收到消息的节点成为了新的leader节点，那么数据还是会丢失。注意，启用幂等性（enable.idempotence = true）要求此配置值为“all”。如果设置了冲突配置并且未显式启用幂等性，则禁用幂等性！
all或-1：acks = all 或-1表示只有当所有同步副本全部收到消息是，生产者才会收到一个来自服务器的成功响应。此种模式是最安全的，可以保证不止一个服务器收到消息，就算有服务器宕机，整个集群仍然可以运行，保证了只要至少有一个同步副本保持活动状态，记录就不会丢失。但是此种模式的延迟也是最高的。

buffer.memory

生产者可以用来缓冲等待发送到服务器的记录的总内存字节数，生产者用它缓冲要发送到服务器的消息。
long类型，默认值为33554432字节（32MB）。
如果应用程序发送消息的速度超过了发送到服务器的速度，会导致生产者空间不足。此时，send()方法要么被阻塞，要么抛出异常，取决于如何设置block.on.buffer.full参数（在0.9.0.0版本里被替换成了max.block.ms，表示在抛出异常之前可以阻塞多长时间）。也就是说，如果记录的发送速度超过了它们可以传递到服务器的速度，则生产者将阻塞max.block.ms时间之后，抛出异常。

compression.type

指定消息被发送给broker之前使用哪一种压缩算法进行压缩。
默认情况下，消息发送时不会被压缩，但是使用压缩可以降低网络传输开销和存储开销。压缩是由整批数据组成的，因此批处理的效率也会影响压缩比，批处理越多意味着压缩效果越好。
string类型，默认值为none，可选值有：

none
gzip：会占用较多的CPU，但是会提供更高的压缩比，所以如果网络带宽有限，可以使用这种算法。
snappy：Google发明的压缩算法，占用较少的CPU，却能提供较好的性能和相当可观的压缩比，如果比较关注性能和网络带宽，可以使用这种算法。
lz4：一种追求极致压缩与解压速度的压缩算法。LZ4算法的主要优势在于压缩与解压的效率高，压缩特别是解压非常快，对于CPU占用少。
5.zstd：Facebook的Yann Collet开发的一种快速的无损压缩算法，是针对 zlib 级别的实时压缩方案，以及更好的压缩比，有更高的压缩和解压缩速度。

retries

指定消息在发送失败之后，重试发送的次数。
int类型，默认是2147483647。
默认情况下，生产者会在每次重试之间等待100ms，不过可以通过retry.backoff.ms参数来设置重试的时间间隔。
kafka生产者一般会产生两种错误。一种是可重试的错误，如连接错误，无主错误等，这类错误可以通过重试解决问题。还有一种错误是不可重试的错误，如消息太大等，对于这类错误，Kafka不会进行重试，而是直接抛出异常。

实践建议

在设置重试次数和重试时间间隔之前，建议先测试一下恢复一个崩溃节点需要多少时间。
例如，所有分区选出leader节点需要多少时间。我们可以设置总的重试时间比Kafka集群从崩溃中恢复的时间长，否则生产者会过早地放弃重试。
一般情况下，因为生产者会自动进行重试，所以没必要在代码逻辑中处理那些可以重试的错误。我们只需要在代码中处理那些不可重试的错误或者重试次数超出上限的情况即可。
用户通常应该不设置此配置，而是使用delivery.timeout.ms来控制重试行为。
如果delivery.timeout.ms配置的超时在成功确认之前先过期了，那么在重试次数用完之前，生产者请求将失败。
启用幂等性要求此配置值大于0。如果设置了冲突配置并且未显式启用幂等性，则禁用幂等性。
在将enable.idempotence设置为false，并将max.in.flight.requests.per.connection设置为1时，设置了重试次数，可能会导致消息的顺序发生变化。因为如果将两个批次发送到一个分区，并且第一个批次失败并重试，但第二个批次成功，则第二个批次中的消息可能会首先出现，即第二个批次的消息跑到第一个批次的消息前面了。

batch.size

指定一个批次可以使用的内存大小（单位：字节）。
int类型，默认16384字节（16KB）。
设置为0表示禁用批次。
当有多个消息需要被发送到同一个分区时，生产者会把它们放在同一个批次中，这样有助于客户端和服务器的性能。
当批次被填满之后，批次里的所有消息会被发送出去。但是，生产者并不一定都会等到批次被填满才发送消息，半满的批次，设置只有一条消息的批次也可能被发送。因此，即使把批次大小设置的很大，也不会造成延迟，只是会占用更多的内存而已。如果把批次设置的太小，生产者需要更频繁地发送消息，会增加额外的开销。
注意，当我们将linger.ms设置为0时，即使累积的批大小小于batch.size设置的值，也会立即发送一条记录。

linger.ms

指定生产者在发送批次之前，等待更多消息加入批次的时间（单位：毫秒）。
long类型，默认值为0，表示没有延迟。
KafkaProducer会在批次被填满或者linger.ms达到上限时将批次发送出去。默认情况下，只要有可用的线程，就算批次里只有一条消息，生产者也会把消息发送出去。
把linger.ms设置为大于0的整数，可以让生产者在发送批次之前等待一会，使更多的消息加入到批次中。这样会增加延迟，但是会增加吞吐量（一次性发送的消息多了，每个消息的开销变小了）。

client.id

指定生产者的id，可以是任意字符串。服务器用它来识别消息的来源，而不仅仅是ip/port，还可以用在日志和配额指标里。
string类型，默认为空。

max.in.flight.requests.per.connection

指定生产者在收到服务器响应之前可以发送多少个消息。该值越高，就会占用越多的内存，不过也会提高吞吐量。
把该值设置为1，可以保证消息是按照发送的顺序写入服务器的，即使发送了重试。
int类型，默认值为5。
注意：如果此配置设置为大于1，并且enable.idempotence设置为false，那么在由于重试而发送失败后（如果启用了重试），存在消息重新排序的风险。如果禁用了重试或enable.idempotence设置为true，则将保留排序。
此外，启用幂等性要求此配置的值小于或等于5。如果设置了冲突配置并且未显式启用幂等性，则禁用幂等性。

timeout.ms

指定broker等等同步副本返回消息确认的时间（单位：毫秒）。如果在指定时间内没有收到同步副本的确认，那么，broker就会返回一个错误。
本配置在Kafka 0.9.0.0中被弃用。

request.timeout.ms

指定生产者在发送数据时等等服务器返回响应的时间（单位：毫秒）。
int类型，默认值30000 (30 秒)。
如果在超时时间过去之前没有收到响应，则客户端将在必要时重新发送请求，或者在重试次数耗尽时使请求失败。
注意：本配置应该大于replica.lag.time.max.ms指定的值，以减少由于不必要的生产者重试而导致消息重复的可能性。

metadata.fetch.timeout.ms

指定生产者在获取元数据（如目标分区的leader）时等待服务器返回响应的时间（单位：毫秒）。如果等待响应超时，那么生产者要么重试发送数据，要么返回一个错误（抛出异常或者执行回调）。
本配置在Kafka 0.9.0.0中被弃用。

max.block.ms

指定在调用KafkaProducer的send、partitionsFor、initTransactions、sendOffsetsToTransaction、commitTransaction 和 abortTransaction方法获取元数据时生产者阻塞的时间（单位：毫秒）。当生产者的发送缓冲区已满，或者没有可用的元数据时，这些方法就会阻塞。在阻塞时间达到max.block.ms时，生产者就会抛出超时异常。
对send方法来说，max.block.ms限制了等待元数据获取和缓冲区分配的总时间。对partitionsFor方法来说，如果元数据不可用，则max.block.ms限制等待元数据所花费的时间。

max.request.size

指定生产者发送的请求大小。可以指发送的单个消息的最大值，也可以指单个请求中所有消息的总大小，实际上也是最大未压缩批大小的上限（单位：字节）。
int类型，默认值为1048576字节。

注意：broker对可接收的消息的最大值也有自己的限制（message.max.bytes），因此，两边的配置最好可以匹配，避免生产者发送的消息被broker拒绝。

receive.buffer.bytes

指定接收数据时要使用的TCP接收缓冲区（SO_RCVBUF）的大小（单位：字节）。
int类型，默认值32768 (32 kb)。如果值为-1，则将使用操作系统默认值。

send.buffer.bytes

指定发送数据时要使用的TCP发送缓冲区（SO_SNDBUF）的大小（单位：字节）。
int类型，131072 (128 kb)。如果值为-1，则将使用操作系统默认值。

孙花菜

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Kafka生产者配置

此时，send()方法要么被阻塞，要么抛出异常，取决于如何设置block.on.buffer.full参数（在0.9.0.0版本里被替换成了max.block.ms，表示在抛出异常之前可以阻塞多长时间）。但是，生产者并不一定都会等到批次被填满才发送消息，半满的批次，设置只有一条消息的批次也可能被发送。注意：broker对可接收的消息的最大值也有自己的限制（message.max.bytes），因此，两边的配置最好可以匹配，避免生产者发送的消息被broker拒绝。指定生产者的id，可以是任意字符串。
复制链接

扫一扫