说实话Docker 安装 Kafka 这个问题我在各种技术群里被问过不下几十次。每次看到有人说Kafka 启动不了端口不通明明容器起来了但消费者连不上我基本能猜到八成是同一个原因外层端口映射没问题但 Kafka 内部的 advertised.listeners 没有配对。这玩意不像 MySQL端口一映射就完事Kafka 的客户端连接还受一层对外广播地址控制不少人就是栽在这上面。这篇文章我会把一套自己反复验证过的步骤完整拆开写从架构选型、镜像选择到 compose 编排、单节点验证、集群扩展和常见故障一次性讲明白。你照着做十分钟内能跑通一个开发环境如果只是想本地试试 Kafka 的 API 和生态工具这篇文章足够用了。1. 装之前必须想清楚的三件事很多人拿到 Kafka 第一反应就是找个安装包按教程跑起来。但如果你直接用 Docker其实不涉及任何安装包只要环境里具备容器运行时剩下的都是配置文件的事。动手之前我建议你先想清楚三个问题为什么用 Docker 跑、用新架构还是老架构、单节点够不够。1.1 为什么要用 Docker 来跑 KafkaKafka 本身依赖 JVM传统本机安装方式要先装 JDK、再下载二进制包、配置环境变量、手动启动 ZooKeeper 和 broker整个过程繁琐且容易受宿主环境影响。我见过有人因为本机装了多个 Java 版本启动 Kafka 时直接报UnsupportedClassVersionError排查半天才发现是 JDK 版本被切走了。Docker 解决的就是这种环境不一致问题。镜像里已经把 Java 运行时和 Kafka 的目录结构打包好你只需要通过环境变量告诉容器Kafka 怎么跑就行了。好处非常明显安装和卸载都干净不会在你机器上留一堆不知名的目录和进程可以同时跑多个不同版本的 Kafka互相不干扰把 compose 文件一提交团队里任何人拉下来就能复现同一套环境出问题了直接删容器重建比在宿主机上修来修去快得多。当然Docker 跑 Kafka 也不是完全没有代价。容器网络比宿主机网络多了一层地址转换Kafka 对外广播的地址如果配置不当就会出现容器内好好的、外面连不上的经典问题。这个问题后面我会专门讲。1.2 新老架构差异KRaft 模式与 ZooKeeper 模式Kafka 早期版本依赖 ZooKeeper 来管理集群元数据、broker 注册、controller 选举。也就是说广义的Kafka 集群实际上是Kafka broker 集群 ZooKeeper 集群两套系统在协同工作。ZooKeeper 本身也是一个分布式协调服务同样需要独立部署。从 Kafka 3.3 版本开始官方引入了 KRaftKafka Raft模式把元数据的管理权收回到 Kafka 自身不再依赖 ZooKeeper。到了 Kafka 4.0ZooKeeper 已经正式被移除。如果你现在刚开始接触 Kafka我强烈建议你直接使用 KRaft 模式的镜像。原因很朴素少一个组件就少一类故障部署、运维、排错的复杂度都低很多。我见过不少旧教程还在教先起两个 ZooKeeper 容器再起 Kafka 容器这套流程不是不能跑只是已经过时了。对于新项目老老实实走 KRaft 是正确选择。如果你需要维护老版本集群或者公司内部还停留在旧架构那可以再单独研究 ZooKeeper 模式。1.3 单节点还是多节点取决于你的目标场景这个问题往往被忽略但会影响配置复杂度。如果你只是学习 API、写个 Demo、验证某条业务逻辑单节点 Kafka 已经完全够用。单节点部署简单也不用考虑副本同步、跨节点网络这些烦心事。但如果你要测试生产环境下的高可用行为比如某个 broker 挂掉之后消息是否还能正常生产消费那就需要至少三个节点的集群。这里提醒一句Kafka 的副本同步机制决定了副本数不能大于 broker 数所以两个节点的集群在生产场景里比较尴尬副本因子设为 2 时一旦一个节点挂掉最小 ISR 可能不满足写入照样失败。真正要做高可用测试老老实实三个节点起步。2. 环境检查和镜像选择动手前的准备工作别急着写 compose 文件先把环境检查这一关过了。我遇到过不少照着教程复制粘贴却起不来的情况最后发现是连 Docker 版本都不满足要求或者 Compose 命令根本不可用。2.1 Docker 与 Compose 环境准备先确认 Docker 引擎版本在终端里执行docker --version建议使用 Docker 20.10 以上的版本太老的版本在资源限制、网络模式方面有各种历史遗留问题。如果你用的是 Linux 服务器大概率装的 Docker Engine 是符合要求的。然后确认 Compose 插件是否可用docker compose version如果你执行报错说明没有安装 Compose 插件。有些老环境可能还在用docker-compose这个独立命令它是 Compose v1原则上也能用但语法和插件版有细微差别。我的建议是统一使用docker compose注意中间有空格这是当前社区的主流写法。如果你是 Windows 或 macOS 上的 Docker Desktop 用户Compose 插件默认自带基本上不用额外配置。Linux 用户如果发现没有装一下 docker-compose-plugin 这个包就行。检查完这两项就可以继续了。2.2 镜像版本选择别再用过时的第三方镜像很多人搜 Kafka Docker 教程时会搜到一些老文章里的wurstmeister/kafka镜像。这个镜像在 Kafka 2.x 时代确实很流行但项目早就停止维护了镜像里的 Kafka 版本还很旧而且它默认还带着 ZooKeeper 依赖的配置习惯。我不建议你用这个镜像。当前最合适的方案是使用 Apache 官方提供的apache/kafka镜像。官方镜像从 Kafka 3.7 左右开始维护支持 KRaft 模式镜像内已经打包好所有脚本和依赖目录结构也规范。建议用apache/kafka:3.7.2或者更新的稳定版本。选镜像时记住一个原则镜像的 tag 要尽量靠近浏览器里能搜到的安全版本不要用latest标签。latest有一天可能指向一个行为完全不同的新大版本到时候升级配置都会跟着变非常被动。我在实际工作中通常会固定到小版本比如apache/kafka:3.9.0这样团队里的复制粘贴结果永远是同一个版本排查问题也方便。2.3 端口、数据卷与资源规划Kafka 默认的客户端连接端口是 9092。使用 bridge 网络时容器内部的 9092 端口需要映射到宿主机上。如果你的宿主机 9092 被占用了可以映射到其他端口比如19092:9092但要注意后面所有连接地址都要跟着改。数据持久化方面容器一旦删除容器内文件系统里的内容就会丢失。因此必须把 Kafka 的数据目录映射到宿主机或者 named volume 上。推荐使用 named volume原因后面我会详细说。资源规划上Kafka 是 JVM 进程生产环境单 broker 一般建议至少 2GB 堆内存机器总内存 4GB 以上。如果只是本地测试给个 512MB 堆也能跑就是分区和消息量一大会变得很慢。CPU 方面一般两个核起步开发环境无所谓但别在单核容器上硬扛高吞吐场景。3. 5分钟跑通docker compose 部署单节点 Kafka基础思路清楚了接下来就是实际操作。我提供一套经过验证的单节点 KRaft 模式配置你照着存成文件就能用。3.1 编写 docker-compose.yml在你的工作目录下新建一个docker-compose.yml文件内容如下services: kafka: image: apache/kafka:3.9.0 container_name: kafka-single ports: - 9092:9092 environment: KAFKA_NODE_ID: 1 KAFKA_PROCESS_ROLES: broker,controller KAFKA_CONTROLLER_QUORUM_VOTERS: 1kafka:9093 KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093 KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1 volumes: - kafka-data:/var/lib/kafka/data volumes: kafka-data:这段配置里的每个环境变量都有明确作用我逐个解释一下KAFKA_NODE_ID给当前节点分配的唯一 ID。单节点集群就写 1多节点时每个节点必须不同。KAFKA_PROCESS_ROLES当前节点承担的角色。broker,controller表示一个节点既是数据节点也参与控制器选举。单节点部署时这是最省事的写法。KAFKA_CONTROLLER_QUORUM_VOTERS控制器集群的成员列表。1kafka:9093表示节点 1 监听在kafka:9093上。注意这里用的是容器名kafka不是localhost容器内部通过 Docker 网络解析到这个服务。KAFKA_LISTENERS节点对外绑定的监听地址。0.0.0.0:9092表示 broker 端口0.0.0.0:9093是控制器通信端口两个都要监听在容器的所有网卡上。KAFKA_ADVERTISED_LISTENERS这是最关键的一行。它告诉客户端你应该连接哪个地址。这里写localhost:9092是给容器内和宿主机上的客户端用的。后面如果要从局域网其他机器访问必须改成宿主机 IP。KAFKA_LISTENER_SECURITY_PROTOCOL_MAP把监听器名映射到对应的安全协议。这里两个都是PLAINTEXT也就是明文连接开发环境够用了。KAFKA_INTER_BROKER_LISTENER_NAMEbroker 之间互通信所用的监听器名指定为PLAINTEXT。KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR__consumer_offsets主题的副本因子。单节点只能设 1。数据卷部分把容器的/var/lib/kafka/data映射到名为kafka-data的 volume 上。这样只要你不主动执行docker compose down -v数据就不会丢。3.2 启动容器与检查日志在 compose 文件所在目录执行docker compose up -d执行完成后再查看日志docker compose logs -f kafka正常情况下几秒到十几秒后日志里会出现类似Kafka Server started或started (kafka.server.KafkaRaftServer)的信息说明 broker 已经成功启动。如果你看到的日志停在某个错误上那就不能继续往下走先把问题解决。可以先docker compose down清掉容器再调整配置重启。关于常见的启动失败原因我会在最后一章集中排查。3.3 快速验证创建主题并进行生产消费Kafka 镜像自带完整的脚本工具我们可以直接在容器内执行。先用命令行创建测试主题docker exec kafka-single /opt/kafka/bin/kafka-topics.sh --create --topic test --partitions 3 --replication-factor 1 --bootstrap-server localhost:9092创建成功后会输出Created topic test。接着打开一个终端进入生产者模式docker exec -it kafka-single /opt/kafka/bin/kafka-console-producer.sh --topic test --bootstrap-server localhost:9092输入几行文本比如hello kafka然后按 CtrlC 退出。另外开一个终端进入消费者模式docker exec -it kafka-single /opt/kafka/bin/kafka-console-consumer.sh --topic test --from-beginning --bootstrap-server localhost:9092如果能看到刚才输入的hello kafka以及之前的历史消息就说明 Kafka 单节点环境已经完全跑通了。这一步验证远比只看进程存在与否靠谱因为它实际上走了一遍完整的消息链路。3.4 宿主机和局域网机器如何连接 Kafka到这里很多会走到第一个大坑容器里生产消费正常但用宿主机上的 Java 程序或 Python 客户端连不上报连接拒绝。原因就出在KAFKA_ADVERTISED_LISTENERS配置上。当你在宿主机上运行客户端并连接localhost:9092时客户端建立连接后会收到 broker 的元数据响应里面写着你以后应该连这个地址。如果配置写的是PLAINTEXT://localhost:9092那么宿主机客户端确实能连但如果你把容器映射成了19092:9092这里就必须写PLAINTEXT://localhost:19092因为客户端需要知道正确的端口。如果要从局域网内的另一台机器连接localhost就不行了。它指向的是那台机器自己根本找不到 Kafka。这时候你要把KAFKA_ADVERTISED_LISTENERS改成宿主机的局域网 IP比如KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://192.168.1.100:9092然后外部机器连接时也写192.168.1.100:9092。注意这里的 IP 必须是客户端能访问到的地址不能是容器 IP。我曾经见过有人直接写容器 IP结果容器一重建 IP 就变了客户端跟着全废。4. 进阶玩法把单节点扩展成多节点集群单节点跑通之后很多人会想试试集群。这个方向是对的毕竟 Kafka 的高可用、分区副本、故障转移这些特性都要在集群里才能体现。但集群的配置比单节点复杂不少尤其在使用 Docker bridge 网络时需要仔细处理容器间互访和外部访问两套地址。4.1 多节点集群编排的两个方案如果是 Linux 服务器网络环境相对可控我建议直接用 host 网络模式这样每个 broker 直接监听宿主机的 IP 和端口省去端口映射的麻烦也避免容器间访问地址错乱的问题。但这种模式在 Docker DesktopmacOS / Windows上不可用所以如果你的开发环境是笔记本电脑还是老老实实用自定义网络加端口映射。我给出一个比较实用的三节点 compose 配置思路。由于 broker 之间通信需要互相通过容器名访问先创建一个自定义网络networks: kafka-net: driver: bridge services: kafka1: image: apache/kafka:3.9.0 container_name: kafka1 ports: - 9092:9092 networks: - kafka-net environment: KAFKA_NODE_ID: 1 KAFKA_PROCESS_ROLES: broker,controller KAFKA_CONTROLLER_QUORUM_VOTERS: 1kafka1:9093,2kafka2:9093,3kafka3:9093 KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092,CONTROLLER://0.0.0.0:9093 KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092 KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER KAFKA_INTER_BROKER_LISTENER_NAME: PLAINTEXT KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 2这里我只展示了 kafka1kafka2 和 kafka3 的服务定义大同小异区别在于容器名、端口映射可以用 9093、9094 映射到宿主机、KAFKA_NODE_ID。三个节点的KAFKA_CONTROLLER_QUORUM_VOTERS必须保持一致都指向这三个容器。特别注意一点KAFKA_ADVERTISED_LISTENERS在集群里如果仍然写localhost:9092那么三个 broker 之间会因为互相访问 localhost 而找不到对方。所以在测试集群里的生产消费时我建议都在容器内执行这样 broker 之间通过容器名互访没问题。如果一定要支持宿主机客户端就需要给每个 broker 配置额外的 listener这个内容比较复杂这里先不展开。4.2 创建多副本主题并观察 ISR集群启动完成后在任一容器内创建一个三副本主题docker exec kafka1 /opt/kafka/bin/kafka-topics.sh --create --topic cluster-test --partitions 3 --replication-factor 3 --bootstrap-server localhost:9092然后用 describe 命令查看分区状态docker exec kafka1 /opt/kafka/bin/kafka-topics.sh --describe --topic cluster-test --bootstrap-server localhost:9092输出里会看到每个分区对应的 Leader 和 Replicas 以及 Isr 列表。正常情况下Replicas 有三个 brokerIsr 也是三个表示所有副本都跟上了 Leader。这时候可以做一个高可用验证手动停掉其中一个 broker 容器再查一遍 Isr。你会发现 Kafka 会自动把 Leader 切换到其他节点只要剩余节点满足最小 ISR 条件生产和消费就不会中断。这个实验对理解到底为什么集群至少三个节点非常有帮助。4.3 集群模式下副本因子与 ISR 的关系配置里经常看到min.insync.replicas这个参数它和副本因子配合使用。比如主题副本因子是 3min.insync.replicas设为 2表示至少有 2 个副本同步成功生产者才会认为写入成功。这样能避免 Leader 单节点假写成功的情况但代价是可用的节点数量变少极端情况下如果只剩 2 个节点写入仍然正常如果只剩 1 个写入就会被拒绝。这个权衡在生产环境非常重要。副本数设得越多容灾能力越强但同步开销和磁盘占用也越大min.insync.replicas设得越高数据越安全但可用性越低。很多生产事故都是因为有人把min.insync.replicas设成了 3而集群曾经由于维护被降到了 2 个节点结果所有写入全部报 NotEnoughReplicasException。这不是 Kafka 的 Bug是配置意图和实际集群规模不匹配。5. 持久化与调优让 Kafka 在 Docker 里更耐用单节点和集群都能跑起来之后就该考虑生产化和长期运行问题了。Docker 容器本身是一次性的如果不做持久化和资源限制你可能会在某次清理容器时发现所有消息都没了。这一章聊几个关键点。5.1 数据卷、日志目录与权限问题Kafka 把消息段文件、索引文件和元数据都写入日志目录。官方镜像里这个目录是/var/lib/kafka/data。我用 named volume 来做持久化示例中的kafka-data:/var/lib/kafka/data已经够了。为什么不推荐 bind mount也就是像./kafka-data:/var/lib/kafka/data这样映射到宿主机目录因为很容易遇到权限问题。容器内的 Kafka 进程可能以非 root 用户运行而宿主机上新建的目录所有者通常是 root二者权限不匹配时容器启动后 Kafka 会因为写不进去数据而报错。使用 named volumeDocker 会负责初始化目录所有权省去你自己 chmod 的麻烦。有一点要牢记docker compose down不会删除 named volume数据会保留但docker compose down -v会连同 volume 一起删掉数据就真没了。我建议在清理环境前先执行docker volume ls确认一下哪个 volume 是你想保留的。血的教训告诉你别轻易带-v。5.2 JVM 堆内存与系统级参数Kafka 进程跑在 JVM 里堆内存设置太小时高吞吐场景下会出现频繁 GC表现为吞吐掉崖、延迟飙升。Docker 部署时可以通过设置KAFKA_HEAP_OPTS环境变量来控制KAFKA_HEAP_OPTS: -Xms2G -Xmx2G-Xms和-Xmx设为相同值是为了避免 JVM 动态扩容引发性能抖动。开发环境可以设小一点比如-Xms512M -Xmx512M。除此之外生产环境还要关注文件描述符限制。Kafka 会打开大量文件容器内默认的 ulimit 可能不够。在 compose 服务里加上ulimits: nofile: soft: 65536 hard: 65536这行的作用是把进程能打开的文件数上限调到 65536减少Too many open files一类错误。5.3 常用配置项速查表这里整理了一份我平时最常调整的配置项覆盖日志保留、自动创建主题等场景。在 Docker 部署中所有原生 Kafka 配置项都可以通过环境变量方式传入规则是把配置项的点号换成下划线并加上KAFKA_前缀比如log.retention.hours对应的环境变量是KAFKA_LOG_RETENTION_HOURS。配置项环境变量示例默认值说明log.retention.hoursKAFKA_LOG_RETENTION_HOURS168日志保留小时数超出后清理旧段log.retention.bytesKAFKA_LOG_RETENTION_BYTES-1按日志总大小清理-1 表示不限制num.partitionsKAFKA_NUM_PARTITIONS1自动创建主题时的默认分区数auto.create.topics.enableKAFKA_AUTO_CREATE_TOPICS_ENABLEtrue生产环境建议改为 false避免误写导致的隐式主题message.max.bytesKAFKA_MESSAGE_MAX_BYTES1048572单条消息最大字节数传大报文时要调大min.insync.replicasKAFKA_MIN_INSYNC_REPLICAS1最小同步副本数生产建议设为 2offsets.topic.replication.factorKAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR1消费者 offset 主题的副本因子生产建议不小于 2不要看到默认值就直接用一定要结合自己的集群规模和消息量做调整。最典型的坑是auto.create.topics.enable保持默认 true结果某个客户端写消息时把主题名多打了一个字符Kafka 自动创建了又一个单分区主题数据全写到那里去了怎么查都查不到。5.4 让 Kafka 在 Docker 环境里更稳的三个小技巧第一给容器设置资源限制。不设置的话Kafka 可能在宿主机内存不足时把整个 Docker 环境拖垮。compose 里加上deploy: resources: limits: memory: 4G第二建议把KAFKA_HEAP_OPTS设置到你预期的使用量上限而不是默认值。如果你发现 GC 频繁优先检查是不是给的内存不够不要一上来就改各种刷盘参数。第三生产环境最好不要把 9092 端口直接暴露到公网。Kafka 默认是明文协议没有任何认证一旦被扫描到轻则数据被读走重则直接被人刷垃圾消息。至少要把它放在内网环境里后续有条件再开启 SASL 认证和 SSL 加密。6. 高频故障排查我踩过的那些坑最后这部分是正文的重头戏。以下问题都是我在实际环境中反复遇到过的每个都有具体的排查思路你如果照抄配置跑不起来可以先来这里对号入座。6.1 容器起来了但宿主机客户端连接被拒现象容器日志一切正常docker exec到容器里生产消费也正常但宿主机上的 Java 或 Python 客户端就是连不上。排查思路首先确认端口占用和监听状态ss -lntp | grep 9092看宿主机上是否真的有进程在监听。如果没有检查 compose 文件的 ports 映射是否写对。如果端口在监听但连接失败最可能的原因是KAFKA_ADVERTISED_LISTENERS配置的地址客户端访问不到。比如它写的是容器 IP而宿主机客户端当然找不到容器 IP。还有一种情况是防火墙拦截。Linux 服务器上容易忽略自带的防火墙需要把对应端口放通。这个问题在你本地电脑上不出现但一到服务器上就暴露了。我的建议是先在宿主机上用最简单的工具验证一下nc -vz localhost 9092。如果这个命令通了客户端还连不上那基本就是 advertised listener 配置的问题把地址改成客户端实际能访问的 IP 即可。6.2 broker 反复重启节点 ID 冲突与旧元数据残留现象容器启动几秒后自动退出日志里报node id 1 is not in the enumerated ...或者Error while creating ...。这种情况多发于两种情况。第一种是你在多个容器上配置了同一个KAFKA_NODE_ID比如复制粘贴多节点配置时忘改 ID。第二是旧数据卷里保留了上次运行的元数据而这次配置的节点 ID 或集群 ID 和旧数据不匹配。解决办法也简单确认每个节点的KAFKA_NODE_ID唯一如果一时不知道是不是数据卷的问题可以先把有问题的容器和数据卷一起清掉重新创建再试。注意清数据卷之前确认里面的消息是否重要。6.3 刚创建完主题马上生产消费报 LeaderNotAvailableException这个错误在测试环境特别常见。原因在于 Kafka 创建主题后Leader 选举需要一点点时间完成。你在创建完成提示出现后立刻发送消息可能正好赶上某个副本还在同步或者控制器还没有把 Leader 信息广播出去。常规做法是等待几秒再重试。如果等了七八秒还报错就要查一下副本数和 broker 数量是否匹配。比如你在单节点集群里创建了一个replication-factor3的主题分区副本永远无法全部上线Leader 自然选不出来生产消费就会持续失败。主题创建时的报错有时候不是即时出现的要在 describe 里看 Isr 是否正常。6.4 多网卡或服务器名导致客户端连接失败Kafka 在 broker 返回给客户端的元数据里包含 advertised 地址。如果你的服务器有多个网卡或者主机名解析有问题可能出现客户端连接的地址和实际地址不一致的情况。我曾经遇到一台服务器有内网和管理网两套网卡localhost没问题但局域网其他机器访问时总是报连接失败。最后发现是 Kafka 的 advertised listener 写的是主机名而该主机名在客户端机器上无法解析。这种情况下直接改成具体的 IP 最省心不要在复杂环境里依赖主机名解析。6.5 数据全没了都是 -v 惹的祸这个问题我见过太多太多次。docker compose down -v会把声明在 compose 里的所有 volume 都删掉包括你的 Kafka 数据卷。很多人清理环境时习惯性地加了-v等再启动的时候发现主题列表空了、历史消息没了才反应过来。我的习惯是把删除指令分成两步先在草稿文件里确认这条命令再执行。如果是测试环境随意无所谓但只要 volume 里有有价值的数据就绝对不要带-v。更好的做法是把数据卷备份到另一个位置比如定期用容器把/var/lib/kafka/data打包上传到对象存储这样即使误删也能恢复。最后说说我的使用体会Docker 跑 Kafka 的磨合期其实就是在和网络配置较劲。Kafka 本身安装不复杂但它的监听器listener模型确实比常规数据库复杂一倍因为客户端连接时先做一次 bootstrap再从元数据里获取真正的连接地址中间任何一个环节不一致都会失败。多配几次之后你会发现所有连接问题到最后都指向同一件事advertised 的地址必须是客户端视角下可达的地址。如果你只是临时想验证消息队列的行为用单节点 KRaft 模式就够了。如果要做功能演示或者跑集成测试可以考虑再把集群模式里的三个节点配置完整感受一下 Leader 切换的过程。建议初次尝试的时候先在测试环境反复删建主题、观察 ISR 变化把 Kafka 的副本和 Leader 选举机制彻底吃透这样再往下看生产级配置就不会心虚了。