Spring Cloud Stream Kinesis Binder 4.0.1：KPL/KCL使用及调优疑问

1. kplKclEnabled与Enhanced Fan-Out的关系 #

• 你的结论正确：当kplKclEnabled设为true时，Enhanced Fan-Out（EFO）会默认开启。
• 可在保留KPL/KCL的前提下禁用EFO：通过配置spring.cloud.stream.kinesis.bindings.<bindingName>.consumer.enhancedFanOut.enabled=false实现，将<bindingName>替换为你实际的绑定名称即可。

2. 降低KCL吞吐量的有效方法及参数细节 #

为什么consumerBackoff和recordsLimit修改无效 #

开启kplKclEnabled后，消费逻辑由KCL（Kinesis Client Library）接管，consumerBackoff和recordsLimit是原生Spring Cloud Stream消费者的参数，会被KCL内部机制覆盖，因此调整这两个参数无法影响KCL的吞吐量。

有效降低吞吐量的配置方式 #

• 调整KCL单次拉取记录数：配置spring.cloud.stream.kinesis.bindings.<bindingName>.consumer.max-records，降低该值可直接减少KCL每次从shard拉取的记录总量。
• 延长拉取间隔：配置spring.cloud.stream.kinesis.bindings.<bindingName>.consumer.idle-between-polls，设置更长的间隔时间，减少KCL的拉取频率。
• 减少消费并发度：降低spring.cloud.stream.kinesis.bindings.<bindingName>.consumer.concurrency的值，减少消费线程数量，从整体上降低吞吐量。

三个参数的配置细节 #

• consumerBackoff
  • 作用：仅在非KPL/KCL模式下生效，当消费者拉取不到记录时，控制重试等待的时间。
  • 配置示例：spring.cloud.stream.kinesis.bindings.input.consumer.consumer-backoff=1000（单位：毫秒）
  • 注意：KPL/KCL模式下该参数被KCL内部重试逻辑覆盖，无效果。
• recordsLimit
  • 作用：仅在非KPL/KCL模式下生效，限制每个消费批次的最大记录数。
  • 配置示例：spring.cloud.stream.kinesis.bindings.input.consumer.records-limit=100
  • 注意：KPL/KCL模式下，该参数被KCL的max-records替代，修改无效。
• idleBetweenPolls
  • 作用：控制两次拉取Kinesis记录之间的空闲间隔，无论是否拉取到记录都会执行该等待。
  • 配置示例：spring.cloud.stream.kinesis.bindings.input.consumer.idle-between-polls=2000（单位：毫秒）
  • 注意：KPL/KCL模式下该参数有效，延长间隔可直接降低拉取频率，从而减少吞吐量。

内容的提问来源于stack exchange，提问作者Gabriel Magalhães