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, 就是不压缩.
可选none, gzip, snappy 和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会降低吞吐. 太大会浪费内存.
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要发送的消息在发送到服务端之前.
retry.backoff.ms
失败请求重试的间隔时间. 默认是100毫秒
transactional.id
用于事务传递的TransactionalId。 这使得可以跨越多个生产者会话的可靠性语义,因为它允许客户端保证在开始任何新事务之前使用相同的TransactionalId的事务已经完成。
如果没有提供TransactionalId,则生产者被限制为幂等传递。 请注意,如果配置了TransactionalId,则必须启用enable.idempotence。
默认值为空,这意味着无法使用事务。
linger.ms
在正常负载的情况下, 要想减少请求的数量. 加上一个认为的延迟: 不是立即发送消息, 而是延迟等待更多的消息一起批量发送.
当达到得了batch.size的同一partition的消息会立即发送, 不管linger.ms的设置. 假如要发送的消息比较少, 会等待指定的时间以获取更多的消息.
默认设置为0 ms(没有延迟).
max.in.flight.requests.per.connection
没有被确认unacknowledge的batch数, 如果设置大于1在retries设置了的情况下会出现消息发送顺序错误.