Spring Cloud Stream Kafka单个消费者生成多份Consumer Config原因咨询

首先可以明确，这个现象和你运行的Confluent Control Centre没有任何关系，3个消费者配置都是你的Spring Cloud Stream应用自身创建的，三个实例的用途分别如下：

1. client.id为consumer-cloudstreams-1的实例：是你定义的eventConsumer对应的业务工作消费者，负责实际拉取Kafka消息投递给你的业务消费逻辑，参数完全匹配你在application.yml里自定义的配置，enable.auto.commit=false是Spring Cloud Stream Kafka binder的默认行为（框架本身会管理偏移量提交，不需要依赖Kafka客户端自动提交），auto.offset.reset=earliest也是消费组首次启动时的默认策略。
2. client.id为consumer-cloudstreams-2的实例：是Kafka binder内部创建的工具类消费者，专门用于分区分配状态监听、消费组偏移量查询、目标Topic存在性校验等运维逻辑，它会复用你配置的自定义消费者参数，所以除了client id自增之外和第一个实例配置完全一致，不会实际消费业务消息，也不会和工作消费者抢占分区。
3. client.id为consumer-cloudstreams-3的实例：这个是Spring Boot Actuator的Kafka健康检查组件默认创建的探活专用消费者，它只会用来和Kafka集群建立连接、探测集群可用性，不会消费业务消息，默认使用框架自带的基础配置，所以你会看到它的enable.auto.commit=true、auto.offset.reset=latest、值反序列化器用了默认的ByteArrayDeserializer，和你自定义的配置不一致，属于正常现象。

如果你不需要Kafka健康检查，可以在application.yml里添加以下配置关闭第三个实例的创建：

management:
  health:
    kafka:
      enabled: false

前两个消费者实例是Kafka binder运行必需的，不会影响你的业务消费逻辑，也不会导致消息重复消费的问题，不需要额外调整。

内容的提问来源于stack exchange，提问作者ng.newbie