重启后Kafka Docker容器CPU占用100%问题求助

云原生阿岚

2026-8-17

问题描述

我在M1 Mac本地通过Docker Compose部署了Bitnami版Kafka与Zookeeper。删除Kafka和Zookeeper的数据卷后重启，容器可正常启动且CPU使用率较低；本地运行6个不同消费者组和2个Node.js生产者脚本时一切正常。但停止消费者后，通过Ctrl-C停止容器再执行docker-compose up重启，虽容器看似启动正常，但生产者和消费者出现连接拒绝错误（偶有连接但无法保持）。Kafka与Zookeeper日志无报错或警告，仅Kafka容器CPU占用率达100%且持续不降，目前只能通过删除相关数据卷解决问题，想咨询该现象的原因。

附docker-compose.yml配置：

version: '3.8'

services:
  zookeeper:
    container_name: zookeeper
    image: 'bitnami/zookeeper'
    pull_policy: always
    environment:
      ALLOW_ANONYMOUS_LOGIN: yes
      ZOOKEEPER_CLIENT_PORT: 2181
      ZOOKEEPER_TICK_TIME: 2000
    ports:
      - '2181:2181'
    volumes:
      - /Users/localuser/Documents/MintMonsterData/zookeeper:/bitnami/zookeeper
  kafka:
    container_name: kafka
    pull_policy: always
    image: 'bitnami/kafka'
    restart: always
    ports:
      - '29092:29092'
    environment:
      KAFKA_CFG_ADVERTISED_HOST_NAME: kafka
      KAFKA_BROKER_ID: 1
      KAFKA_CFG_ZOOKEEPER_CONNECT: zookeeper:2181
      KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP: CLIENT:PLAINTEXT,EXTERNAL:PLAINTEXT
      KAFKA_CFG_LISTENERS: CLIENT://:9092,EXTERNAL://:29092
      KAFKA_CFG_ADVERTISED_LISTENERS: CLIENT://kafka:9092,EXTERNAL://localhost:29092
      KAFKA_CFG_INTER_BROKER_LISTENER_NAME: CLIENT
      KAFKA_CFG_LOG_RETENTION_HOURS: 24
      ALLOW_PLAINTEXT_LISTENER: yes
      KAFKA_CFG_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
    volumes:
      - /Users/localuser/Documents/MintMonsterData/kafka:/bitnami/kafka
    depends_on:
      - zookeeper

问题原因分析

元数据与Zookeeper状态不一致：Ctrl-C强制停止容器时，Kafka可能来不及向Zookeeper同步最新元数据（如消费者组偏移量、会话状态）。重启后Kafka尝试从Zookeeper加载状态，二者数据不匹配导致内部循环重试或资源死锁，最终CPU跑满。删除数据卷相当于重置所有状态，因此恢复正常。
残留消费者会话未清理：停止消费者后直接终止容器，消费者的Zookeeper会话可能因超时机制未及时失效。重启Kafka后，它会尝试处理这些残留会话，但消费者已不存在，导致Kafka反复尝试清理或重连，CPU占用飙升，同时阻塞新连接请求，出现连接拒绝。
M1架构适配的潜在问题：Bitnami Kafka镜像虽支持ARM64，但强制停止再重启场景下，可能存在文件锁或进程残留问题——M1的Docker基于Rosetta或原生ARM运行，强制停止时Kafka的后台进程或文件锁未被正确释放，重启后进程陷入无限循环占用CPU，无法正常处理新连接。
日志恢复的IO与负载压力：配置中日志保留24小时，若此前运行过大量生产消费任务，日志文件数量较多。容器重启时Kafka需扫描大量旧日志恢复状态，结合M1本地磁盘IO特性，可能导致日志恢复过程异常，CPU持续高负载，进而无法响应新连接。

内容的提问来源于stack exchange，提问作者steddyman