Java kafka producer 的常用参数的意义说明及建议

生产端核心参数

1. acks

参数说明:这是一个非常重要的参数,表示指定分区中成功写入消息的副本数量,这是Kafka生产端消息的持久性(durability)保证。只有当leader确认已成功写入消息的副本数后,才会给Producer发送响应,此时消息才可以认为“已提交”。该参数影响着消息的可靠性以及生产端的吞吐量,并且两者往往相向而驰,通常消息可靠性越高则生产端的吞吐量越低,反之亦然。acks有3个取值:

  • acks = 0:表示生产端发送消息后立即返回,不等待broker端的响应结果。通常此时生产端吞吐量最高,消息发送的可靠性最低。

  • acks = 1: 表示leader副本成功写入就会响应Producer,而无需等待ISR(同步副本)集合中的其他副本写入成功。这种方案提供了适当的持久性,保证了一定的吞吐量。默认值即是1。

  • acks = all或-1: 表示不仅要等leader副本成功写入,还要求ISR中的其他副本成功写入,才会响应Producer。这种方案提供了最高的持久性,但也提供了最差的吞吐量。

调优建议:建议根据实际情况设置,如果要严格保证消息不丢失,请设置为all或-1;如果允许存在丢失,建议设置为1;一般不建议设为0,除非无所谓消息丢不丢失。

2. max.request.size

参数说明:这个参数比较重要,表示生产端能够发送的最大消息大小,默认值为1048576,即1M。

调优建议:一般而言,这个配置有点小,为了避免因消息过大导致发送失败,建议适当调大,比如调到10485760即10M。

3. retries

参数说明:表示生产端消息发送失败时的重试次数,默认值为0,表示不进行重试。这个参数一般是为了解决因瞬时故障导致的消息发送失败,比如网络抖动、leader换主,其中瞬时的leader重选举是比较常见的。因此这个参数的设置显得非常重要。

另外为了避免频繁重试的影响,两次重试之间都会停顿一段时间,受参数retry.backoff.ms,默认为100ms,通常可以不调整。

调优建议:这里要尽量避免消息丢失,建议设置为一个大于0的值,比如3或者更大值。

4. compression.type

参数说明:表示生产端是否对消息进行压缩,默认值为none,即不压缩消息。压缩可以显著减少网络IO传输、磁盘IO以及磁盘空间,从而提升整体吞吐量,但也是以牺牲CPU开销为代价的。当前Kafka支持4种压缩方式,分别是gzip、snappy、lz4 及 zstd(Kafka 2.1.0开始支持)。

调优建议:出于提升吞吐量的考虑,建议在生产端对消息进行压缩。对于Kafka而已,综合考虑吞吐量与压缩比,建议选择lz4压缩。如果追求最高的压缩比则推荐zstd压缩。

5. buffer.memory

参数说明:表示生产端消息缓冲池或缓冲区的大小,默认值为33554432,即32M。这个参数基本可以认为是Producer程序所使用的内存大小。

当前版本中,如果生产消息的速度过快导致buffer满了的时候,将阻塞max.block.ms(默认60000即60s)配置的时间,超时将会抛TimeoutException异常。在Kafka 0.9.0及之前版本,建议设置另一个参数block.on.buffer.full为true,该参数表示当buffer填满时Producer处于阻塞状态并停止接收新消息而不是抛异常。

调优建议:通常我们应尽量保证生产端整体吞吐量,建议适当调大该参数,也意味着生产客户端会占用更多的内存。也可以选择不调整。

6. batch.size

参数说明:发送到缓冲区中的消息会被分为一个一个的batch,分批次的发送到broker 端,这个参数就表示batch批次大小,默认值为16384,即16KB。因此减小batch大小有利于降低消息延时,增加batch大小有利于提升吞吐量。

调优建议:通常合理调大该参数值,能够显著提升生产端吞吐量,比如可以调整到32KB,调大也意味着消息会有相对较大的延时。

7. linger.ms

参数说明:用来控制batch最大的空闲时间,超过该时间的batch也会被发送到broker端。这实际上是一种权衡,即吞吐量与延时之间的权衡。默认值为0,表示消息需要被立即发送,无需关系batch是否被填满。

调优建议:通常为了减少请求次数、提升整体吞吐量,建议设置一个大于0的值,比如设置为100,此时会在负载低的情况下带来100ms的延时。

8. request.timeout.ms

参数说明:这个参数表示生产端发送请求后等待broker端响应的最长时间,默认值为30000,即30s,超时生产端可能会选择重试(如果配置了retries)。

调优建议:该参数默认值一般够用了。如果生产端负载很大,可以适当调大以避免超时,比如可以调到60000。

9. max.in.fight.requests.per.connection

参数说明:这个参数非常重要,表示生产端与broker之间的每个连接最多缓存的请求数,默认值为5,即每个连接最多可以缓存5个未响应的请求。这个参数通常用来解决分区乱序的问题。

调优建议:为了避免消息乱序问题,建议将该参数设置为1,表示生产端在某个broker响应之前将无法再向该broker发送消息请求,这能够有效避免同一分区下的消息乱序问题。

无消息丢失配置

Producer既要保证吞吐量,又要确保无消息丢失。结合上面的参数介绍,这里给出消息无丢失的配置列表,如下:

  • acks = all or -1

  • retries = 3

  • max.in.fight.requests.per.connection = 1

  • 使用带回调机制的send方法即send(record, callback)发送消息,并对失败消息进行处理

  • unclean.leader.election.enable = false

  • replication.factor = 3

  • min.insync.replicas = 2

  • enable.auto.commit = false

前3个参数本文已介绍。最后一个是消费端参数,表示禁用自动提交,后面我们再介绍。其他几个属于broker端的参数。

其中比较难理解的是min.insync.replicas,这个参数表示ISR集合中的最少副本数,默认值是1,并只有在acks=all或-1时才有效。acks与min.insync.replicas搭配使用,才能为消息提供最高的持久性保证。我们知道leader副本默认就包含在ISR中,如果ISR中只有1个副本,acks=all也就相当于acks=1了,引入min.insync.replicas的目的就是为了保证下限:不能只满足于ISR全部写入,还要保证ISR中的写入个数不少于min.insync.replicas。常见的场景是创建一个三副本(即replication.factor=3)的topic,最少同步副本数设为2(即min.insync.replicas=2),acks设为all,以保证最高的消息持久性。

©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页