• Kafka Producer配置解读(转载)


    https://atbug.com/kafka-producer-config/

    bootstrap.servers

    一组host和port用于初始化连接. 不管这里配置了多少台server, 都只是用作发现整个集群全部server信息. 这个配置不需要包含集群所有的机器信息. 但是最好多于一个, 以防服务器挂掉.

    key.serializer

    用来序列化key的Serializer接口的实现类.

    value.serializer

    用来序列化value的Serializer接口的实现类

    acks

    producer希望leader返回的用于确认请求完成的确认数量. 可选值 all, -1, 0 1. 默认值为1

    • acks=0 不需要等待服务器的确认. 这是retries设置无效. 响应里来自服务端的offset总是-1. producer只管发不管发送成功与否。延迟低,容易丢失数据。
    • acks=1 表示leader写入成功(但是并没有刷新到磁盘)后即向producer响应。延迟中等,一旦leader副本挂了,就会丢失数据。
    • acks=all等待数据完成副本的复制, 等同于-1. 假如需要保证消息不丢失, 需要使用该设置. 同时需要设置unclean.leader.election.enable为true, 保证当ISR列表为空时, 选择其他存活的副本作为新的leader.

    buffer.memory

    producer可以使用的最大内存来缓存等待发送到server端的消息. 如果消息速度大于producer交付到server端的阻塞时间max.block.ms, 将会抛出异常. 默认值33554432 byte (32m). 这个设置不是一个严格的边界, 因为producer除了用来缓存消息, 还要用来进行压缩.

    compression.type

    producer压缩数据的类型, 默认为none, 就是不压缩. 可选nonegzipsnappy 和lz4. 压缩整个batch的数据, 因此batch的效果对压缩率也有影响. 更多的批处理意味着更好的压缩

    retries

    设置大于零的值将导致客户端重新发送其发送失败并发生潜在的瞬时错误的记录. 相当于client在发送失败的时候会重新发行. 如果设置了retries而没有将max.in.flight.request.per.connection设置为1, 在两个batch发送到同一个partition时有可能打乱消息的发送顺序(第一个发送失败, 而第二个发送成功)

    batch.size

    producer会尝试批量发送属于同一个partition的消息以减少请求的数量. 这样可以提升客户端和服务端的性能. 默认大小是16348 byte (16k).

    发送到broker的请求可以包含多个batch, 每个batch的数据属于同一个partition.

    太小的batch会降低吞吐. 太大会浪费内存.

    client.id

    发送请求时传递给服务端的id字符. 用来追溯请求源, 除了使用ip/port. 服务端的请求日志中会包含一个合理的应用名. 默认为空

    linger.ms

    在正常负载的情况下, 要想减少请求的数量. 加上一个认为的延迟: 不是立即发送消息, 而是延迟等待更多的消息一起批量发送. 类似TCP中的Nagle算法. 当获得了batch.size的同一partition的消息会立即发送, 不管linger.ms的设置. 假如要发送的消息比较少, 会等待指定的时间以获取更多的消息.

    默认设置为0 ms(没有延迟).

    max.block.ms

    控制KafkaProducer.send()KafkaProducer.partitionsFor()的阻塞时间. 这些方法会因为buffer满了或者metadata不可用而阻塞. 用户设置在serializers或者partitioner中的阻塞不会计算在内.

    max.request.size

    请求的最大大小(以字节为单位)。 此设置将限制生产者在单个请求中发送的记录批次数,以避免发送巨大的请求。 这也是最大记录批量大小的上限。 请注意,服务器拥有自己的记录批量大小,可能与此不同。

    partitioner.class

    Partitioner接口的实现类, 默认是org.apache.kafka.clients.producer.internals.DefaultPartitioner. 需要处理数据倾斜等原因调整分区逻辑的时候使用.

    request.timeout.ms

    配置控制客户端等待请求响应的最长时间。 如果在超时之前未收到响应,客户端将在必要时重新发送请求,如果重试耗尽,则该请求将失败。 这应该大于replica.lag.time.max.ms(broker配置),以减少由于不必要的生产者重试引起的消息重复的可能性。

    enable.idempotence

    设置为’true’, 将开启exactly-once模式. 设置为’false’(默认值), producer会因为borker失败等原因重试发送, 可能会导致消息重复.

    设置为’true'时需要结合max.in.flight.requests.per.connection设为’1'和retires不能为’0’, 同时acks需要设置为’all'或者’'-1’.

    interceptor.classes

    一组ProducerInterceptor接口的实现类, 默认为null. 可以通过该接口的实现类去拦截(可能需要修改)producer要发送的消息在发送到服务端之前.

    max.in.flight.requests.per.connection

    没有被确认unacknowledge的batch数, 如果设置大于1在retries设置了的情况下会出现消息发送顺序错误.

    retry.backoff.ms

    失败请求重试的间隔时间. 默认是100毫秒

    transaction.timeout.ms

    事务协调器等待producer更新事务状态的最大毫秒数, 超过的话事务协调器会终止进行中的事务. 如果设置的时间大于broker的max.transaction.timeout.ms会收到InvalidTransactionTimeout错误.

    transactional.id

    用于事务传递的TransactionalId。 这使得可以跨越多个生产者会话的可靠性语义,因为它允许客户端保证在开始任何新事务之前使用相同的TransactionalId的事务已经完成。 如果没有提供TransactionalId,则生产者被限制为幂等传递。 请注意,如果配置了TransactionalId,则必须启用enable.idempotence。 默认值为空,这意味着无法使用事务。

  • 相关阅读:
    setsid
    dup
    信号量
    linux标准输入输出
    linux守护进程范例
    c++字符串操作
    浏览器缓存
    bfc
    苹果手机自制铃声
    vue-cli 源码解读
  • 原文地址:https://www.cnblogs.com/lzh1043060917/p/14514202.html
Copyright © 2020-2023  润新知