企业官网建设流程全解析

在分布式系统这个圈子里待久了，你会发现一个绕不开的组件就是消息队列，而Kafka又是消息队列里怎么都绕不开的那一个。很多团队把Kafka当作数据中枢，既要从业务系统里收集日志和埋点，又要给下游的数据分析、实时计算供数，还要承担应用之间的异步解耦。真正上手之后，你会发现Kafka的核心原理并不复杂，真正劝退新人的往往是一堆乱七八糟的概念和线上故障。这篇文章我就从入门到实际落地，把Kafka里你一定会碰、也一定会用到的那些东西一次性讲清楚，包括核心架构、基础操作、代码示例、调优参数和典型故障排查思路。不管你是刚接触消息队列的新人，还是已经用过一段时间想系统梳理一遍的开发者，都能从这篇文章里找到可以直接照着用的内容。

1. 为什么要选Kafka：消息队列的核心价值与适用场景

1.1 从直接调用到异步解耦：消息队列到底解决什么问题

先从一个最朴素的场景说起。某个系统注册新用户之后，需要发欢迎短信、送优惠券、更新用户画像、同步到搜索索引。如果这些动作都在注册请求里同步完成，接口会变得很慢，而且任何一个下游服务挂了都会导致注册失败。更麻烦的是，注册模块根本不需要关心发短信的具体逻辑，也不应该知道送券服务的内部实现，但代码上却耦合得死死的。

引入消息队列之后，注册模块只需要往某个主题里塞一条“用户注册成功”的消息，然后立刻返回成功。下游的短信服务、券服务、画像服务、搜索同步服务各自订阅这个主题，拿到消息后做自己的事情。这样注册接口的耗时从处理四五件事变成发一条网络请求，性能明显提升；下游出故障也不会阻塞注册主流程；需要增加新消费者时，只需再写一个服务订阅同一个主题，不用改动注册模块。

这里体现的就是异步解耦和流量削峰。流量高峰时，比如秒杀或者大促，系统瞬间涌入的请求如果直接打到数据库，数据库基本扛不住。中间放一个Kafka，生产者把消息快速写入，消费者按照自己的处理能力慢慢消费，相当于把突刺的流量拉平了。Kafka在这类场景里特别能扛，因为它的写入模型是顺序追加，单分区内消息顺序写磁盘，吞吐量能到每秒几十万甚至上百万条次级，所以很多公司把它当中央数据总线用。

1.2 Kafka的独特定位：不只是消息队列，更是流处理平台

很多资料喜欢把Kafka和传统的消息中间件放在一起比较。Kafka一开始确实是为日志聚合设计的，设计目标就是高吞吐、分布式、多副本。但它和RabbitMQ、ActiveMQ这类面向点对点和发布订阅的传统MQ有一个很关键的区别：Kafka天生是个分布式日志系统，它把每条消息当作一条带偏移量（offset）的记录，消费者可以通过重置偏移量重新消费历史数据，消息不会因为被消费就马上删除，而是按照保留策略存放一段时间。

这个特性让Kafka不只是做应用解耦，还形成了自己的生态。基于Kafka可以构建实时数据管道，配合流处理框架做实时计算。Kafka本身也提供了 Streams 库，可以在应用内部对消息流做过滤、聚合、连接等操作。再加上 Kafka Connect 用来连接外部数据源，整个体系已经是一个轻量级的流处理平台。不过普通用户不需要一开始就跑到这块，先掌握核心的生产消费链路，再逐步扩展。

1.3 什么时候不建议用Kafka

也不能因为Kafka名气大就盲上。有些场景用Kafka反而会带来不必要的复杂度。比如消息量很小，一天就几千条，团队对运维又不太熟悉，那么用个简单的Redis队列或者关系库里的队列表就足够。延迟要求特别苛刻，希望在几十毫秒内完成端到端消息投递的，Kafka默认的批处理和轮询模型不一定合适，虽然优化后能做到毫秒级，但比专业的低延迟消息系统还是要费更多心思。还有，如果业务只需要一个轻量级的“即发即弃”通知，比如发个邮件提醒，引入Kafka要维护集群、配置磁盘、监控消费者，运维成本并不低。

记住一点：技术选型要看团队规模和业务阶段。消息量还没起来的时候，越简单越好。等真的遇到堆积、削峰、回溯消费的需求时，再来上Kafka，那个时机是最合适的。

2. Kafka核心概念速通：先看懂这几张牌

2.1 记录、主题、分区与偏移量

Kafka里一条消息的正式名称是“记录（Record）”。记录由键、值、时间戳和可选的消息头组成。键的作用主要是决定这条记录发送到哪个分区，同时也能用在日志压缩等高级场景里。值就是业务真正的数据体，通常是JSON、Avro或者Protobuf序列化后的字节。

一堆相同业务类型的记录放到一起，就是“主题（Topic）”。主题是一个逻辑概念，真正存储消息的单位是“分区（Partition）”。创建主题时可以指定分区数，分区数决定了主题的并行处理能力。每条消息写入某个分区时，Kafka会给它一个递增的序号，这个序号就叫“偏移量（Offset）”。偏移量是分区内的，不是全局的，同一个分区内偏移量严格递增，不同分区之间没有顺序关系。

这样设计的核心思想是：单个分区内部保证有序，多个分区之间不承诺全局有序。这从根本上缓解了分布式系统里顺序一致性的瓶颈。如果你需要严格的顺序保证，就把相关消息都发到同一个分区，比如把同一个用户ID的消息通过键哈希到固定分区，这样该用户的事件就能按顺序消费。

2.2 生产者：分区策略与发送模型

生产者客户端负责把消息发送到Kafka集群。发送时它需要决定这条消息进入哪个分区。默认的分区器逻辑是这样的：如果消息指定了分区，直接使用；没指定但带了键，就对键做哈希，再对分区数取模得到分区；键也没有，就用黏性分区策略，也就是随机选一个分区后，尽量把一个批次的消息都塞到同一个分区，减少网络请求和分区切换开销。这是Kafka做得很聪明的优化点，看起来是“随机”，实际上尽量保持了高吞吐。

生产者发送消息是异步的，默认情况下发送方法调用后，消息会进入一个内存缓冲池（RecordAccumulator），发送线程会攒一批消息再发出去，这样减少了网络往返次数。正因为是异步，代码里即使你只管发，不关心结果，也要记得检查发送后的回调或者Future，否则消息发送失败时你连日志都看不到，这是很多新手踩过的坑。

2.3 消费者与消费者组

消费者订阅主题，从分区里拉取数据。Kafka的消费模型是“拉模型”，也就是消费者主动去Broker端拉数据，而不是Broker把数据推给消费者。拉模型的好处是消费者可以根据自己的处理能力控制消费节奏，处理不过来就少拉一点，处理得快就多拉一点，不会像推模型一样可能压垮消费端。

消费者之间通过“消费者组（Consumer Group）”协调工作。一个消费者组是一个逻辑订阅者。同一个消费者组内的多个消费者，会分工消费各个分区。分区与消费者的对应关系是：一个分区最多只能被同一个组里的一个消费者消费，但一个消费者可以消费多个分区。如果组里的消费者数量大于分区数，就会有消费者空闲，这是正常的，不要担心它为啥没活干。

消费者组还提供了自动重平衡（Rebalance）机制。当组里有消费者加入、离开或者分区数发生变化时，协调器会触发重平衡，把分区重新分配给组内消费者。重平衡期间整个消费会暂停一小段时间，增加消费者应该尽量在业务低峰期做，否则频繁重平衡反而会影响消费进度。

2.4 副本机制和ISR

副本是Kafka保证高可用的基础。每个分区的数据可以在多个Broker上保留副本，其中一个副本是Leader，负责处理读写请求，其他副本是Follower，只负责从Leader同步数据。Follower同步的速度有快有慢，Kafka会用“ISR（In-Sync Replicas，同步中副本）”集合来维护跟得上Leader的副本列表。

Leader发生故障时，Kafka会从ISR里选一个新的Leader出来继续对外服务。这保证已经同步成功的消息不会丢。但ISR里的副本数量可以配置，参数min.insync.replicas可以控制最少有几个同步副本才算写成功。如果你的业务对消息丢失零容忍，通常会把这个参数和生产者端的acks=all配合使用，确保一条消息至少被多个副本写入后才算成功。

这里有一个容易混淆的点：复制因子和ISR不等同。复制因子是主题配置，指总共有多少个副本，比如replication-factor=3表示三个副本。ISR是一个动态集合，某个副本如果长时间同步落后，会被踢出ISR，但它仍然算一个副本，只是没资格当Leader。理解这一点对排查“高可用为什么还是丢消息”很有帮助。

3. 环境搭建与基础操作：本机快速跑通

3.1 下载与启动（单机版）

先把环境跑起来，再学概念也不晚。Kafka本身是用Java写的，所以需要机器上有JDK，建议用8或11。到官网下载二进制发行版，解压后目录里会有bin、config、libs等目录。

Kafka早期强依赖ZooKeeper，即使单机版也需要先启动ZooKeeper再启动Kafka。做过一段时间之后你会发现，这对运维来说是个负担。现在Kafka推出了KRaft模式，可以不再依赖ZooKeeper，不过目前很多公司还在用ZooKeeper模式，所以两边都了解一下没有坏处。本地学习的话，直接用自带的脚本就行：

# 启动ZooKeeper（使用Kafka自带脚本，路径按实际解压位置调整） bin/zookeeper-server-start.sh config/zookeeper.properties # 启动Kafka Broker，默认端口9092 bin/kafka-server-start.sh config/server.properties

启动完之后确认进程还在，再跑一个kafka-topics.sh的脚本就能看到效果：

bin/kafka-topics.sh --bootstrap-server localhost:9092 --list

如果是新环境，这个命令会返回空列表，说明集群是通的。注意现在新版脚本都用--bootstrap-server取代了老的--zookeeper去连接集群，这种变化也暗示了去ZooKeeper的趋势。

3.2 用命令行脚本走一遍生产消费

启动成功后，创建一个名字叫demo-events的主题，3个分区，1个副本：

bin/kafka-topics.sh --bootstrap-server localhost:9092 \ --create --topic demo-events \ --partitions 3 --replication-factor 1

创建好之后，可以用控制台生产者发几条消息，再用控制台消费者收回来。生产者的写法是输入一行发送一行，默认用回车作为分隔：

bin/kafka-console-producer.sh --bootstrap-server localhost:9092 --topic demo-events

启动之后输入hello kafka，回车，再输入second message，回车。另开一个终端，启动控制台消费者，注意加--from-beginning表示从最早的消息开始消费：

bin/kafka-console-consumer.sh --bootstrap-server localhost:9092 \ --topic demo-events --from-beginning

正常情况下两条消息都会显示出来。这里要提醒一下：不加--from-beginning时，消费者只会从启动之后新产生的消息开始读，之前的历史消息不会被读到。这个行为和消费者组里的提交偏移量有关，后面代码部分会再细说。

3.3 清理测试环境

测试结束以后，可以直接把进程停掉。如果不想留着主题，删除主题的命令是：

bin/kafka-topics.sh --bootstrap-server localhost:9092 \ --delete --topic demo-events

不过别忘了，delete.topic.enable需要设置为true，否则删除命令只是标记删除，主题在重启后又会出现。这也是很多人和主题“死缠烂打”的一个坑。

单机版跑通之后，你对Kafka的基本操作就有了体感。接下来最大的挑战是从“会用脚本”到“会用代码”，毕竟项目里不可能用控制台生产者和消费者去对接业务。

4. 用代码写第一个生产者与消费者

4.1 依赖准备

我习惯用Java来演示，是因为Kafka客户端的Java生态最成熟，其他语言的客户端也基本参照Java版实现。如果你用Maven，只需要引入一个依赖：

<dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-clients</artifactId> <version>3.6.0</version> </dependency>

如果项目里用的是Spring Boot，可以直接引spring-kafka，它帮你封装了KafkaTemplate和@KafkaListener，底层仍然是kafka-clients。不过我还是建议先裸写一遍客户端代码，这样你能看到每个参数实际在干嘛，后面用框架封装出问题时，定位思路会更清楚。

4.2 生产者示例与参数说明

创建一个KafkaProducer需要三个必填参数：bootstrap.servers指定Broker地址；key.serializer和value.serializer指定键和值的序列化类。最简单的代码如下：

import org.apache.kafka.clients.producer.KafkaProducer; import org.apache.kafka.clients.producer.ProducerConfig; import org.apache.kafka.clients.producer.ProducerRecord; import org.apache.kafka.clients.producer.RecordMetadata; import java.util.Properties; import java.util.concurrent.Future; public class SimpleProducer { public static void main(String[] args) throws Exception { Properties props = new Properties(); props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092"); props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer"); props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringSerializer"); KafkaProducer<String, String> producer = new KafkaProducer<>(props); ProducerRecord<String, String> record = new ProducerRecord<>("demo-events", "userId-123", "register-success"); // 同步发送：等待结果 Future<RecordMetadata> future = producer.send(record); RecordMetadata metadata = future.get(); System.out.println("offset=" + metadata.offset() + ", partition=" + metadata.partition()); producer.close(); } }

这段代码里，键传的是"userId-123"，值传的是业务内容。send方法返回一个Future，调用get()会阻塞到消息发送完成。生产环境里通常不推荐每条消息都用get()，因为异步才是Kafka高吞吐的保障。更合理的做法是使用回调：

producer.send(record, (metadata, exception) -> { if (exception != null) { System.err.println("发送失败: " + exception.getMessage()); // 这里做重试、记录日志或者做降级处理 } else { System.out.println("partition=" + metadata.partition() + ", offset=" + metadata.offset()); } });

回调的好处是可以把发送动作异步化，同时还能感知失败。要注意Callback是在IO线程里执行的，不要在回调里做耗时的阻塞操作，否则会拖慢所有消息的发送。

4.3 消费者示例与提交方式

消费者的代码比生产者稍微复杂一点，关键在于“拉取”和“提交偏移量”的配合。一个基本的消费者：

import org.apache.kafka.clients.consumer.*; import java.time.Duration; import java.util.List; import java.util.Properties; public class SimpleConsumer { public static void main(String[] args) { Properties props = new Properties(); props.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, "localhost:9092"); props.put(ConsumerConfig.GROUP_ID_CONFIG, "demo-group"); props.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer"); props.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.StringDeserializer"); props.put(ConsumerConfig.AUTO_OFFSET_RESET_CONFIG, "earliest"); KafkaConsumer<String, String> consumer = new KafkaConsumer<>(props); consumer.subscribe(List.of("demo-events")); while (true) { ConsumerRecords<String, String> records = consumer.poll(Duration.ofMillis(1000)); for (ConsumerRecord<String, String> record : records) { System.out.printf("partition=%d, offset=%d, key=%s, value=%s%n", record.partition(), record.offset(), record.key(), record.value()); } // 提交偏移量 consumer.commitSync(); } } }

这段代码里group.id是消费者组的名字，同一个组内的消费者共享消费进度。auto.offset.reset的作用是：当这个组在某个分区上没有已提交的偏移量时，决定从哪开始消费。earliest表示从最早消息开始，latest表示从最新开始。如果是新组，没提交过偏移量，用earliest会把历史消息都消费一遍，务必确认业务是否能接受。

consumer.poll()是消费者主动去拉一批数据回来，参数Duration表示最多阻塞等待多久。拿到数据后处理完，再调用commitSync()提交偏移量，表示这些消息我已经处理完了。提交偏移量有两类方式：自动提交和手动提交。默认是自动提交，enable.auto.commit=true，它会周期性提交当前拉取到的最大偏移量。看起来省事，但风险很大，因为自动提交的周期默认是5秒，如果在这5秒内处理完消息后进程挂掉，重启时会从上次自动提交的位置开始消费，导致部分消息重复消费。手动提交更可控，你可以处理完一批消息后再提交，做到“至少一次”的语义。极端情况下手动提交也会因为处理成功但没来得及提交导致重复，这是分布式系统里无法完全避免的，只能靠幂等消费去兜底。

4.4 序列化与反序列化的坑

Kafka在网络上传输的数据都是字节数组，所以生产端要序列化，消费端要反序列化。最常用的就是String，如果你传的是JSON对象，直接用String也能塞进去，但要注意字符编码统一，JSON里的中文乱码大概率就是编码问题。

很多人传对象时习惯用Java自带的ObjectOutputStream做序列化或者直接没用序列化器就去发自定义对象，然后消费端各种ClassNotFoundException。更好的做法是用 Avro、Protobuf 或 JSON 这种跨语言兼容的格式，结合Schema Registry管理版本。不过入门阶段直接用String存JSON把业务跑通，再考虑引入更重的序列化方案。另外，生产者和消费者的序列化器必须配对，生产者用StringSerializer发字符串，消费者用StringDeserializer接，换成其他类型就会报反序列化异常。

5. 关键配置与性能调优：从能跑到跑好

5.1 生产者acks与重试

acks是生产者一个特别重要的参数，它决定了对写入可靠性的要求。有三个取值：

如果你做的是支付、订单这类数据一致性要求很高的业务，必须把acks设为all，再配合min.insync.replicas设置，比如副本因子是3，min.insync.replicas=2，这样至少有两个副本同步成功才算写入成功，即使一个副本挂了，也不会出现返回成功但数据只有一个副本的情况。

retries参数控制生产者发送失败后的重试次数。默认值已经从0改成了很大的值，所以一般不用特别调。但要注意，重试可能导致消息乱序。比如一条消息发送超时，重试期间第二条消息已经发到了别的Broker并成功写入了，重试的第一条消息再写入时，顺序就颠倒了。如果业务强依赖消息顺序，需要设置max.in.flight.requests.per.connection为1，或者用Kafka 2.x之后的幂等生产者，它能在分区内通过序列号保证顺序和去重。

5.2 消费者拉取模型与max.poll.records

消费者每次poll返回多少条数据是由max.poll.records控制的。默认值是500条，如果你每条消息处理耗时比较长，比如每条都调外部接口，一次拉500条可能要处理几十秒。这时候会比较危险，因为消费者有一个心跳机制，如果两次poll间隔超过max.poll.interval.ms，默认300秒，协调器会认为这个消费者已经死了，触发重平衡，把它的分区分给别的消费者，而它自己则会被踢出组。

解决思路有三个方向：一是调低max.poll.records，比如改成100，减少单次处理量；二是加长max.poll.interval.ms；三是在处理消息时，如果确实耗时很长，可以在处理循环里调用poll并指定更短的超时，或者使用单独的心跳线程。最简单有效的还是把单条消息处理得足够快，尽量不要在线程里做太重的事，可以投递到线程池异步处理，但要小心线程池排队的消息在进程宕机时丢失。

5.3 分区数量与消费并发的关系

前面说过分区是Kafka并行度最基本的单位。生产者的吞吐和消费者的并发都受分区数制约。如果一个主题有3个分区，消费者组里最多只有3个消费者能同时消费，第4个消费者只能闲置。反过来想提高消费能力，要么增加分区，要么在单条消息处理流程里做并行。

分区数在主题创建之后可以增加，但不能减少。增加分区会引起消费者重平衡，并且原先基于键哈希的分区策略会导致同一键的消息落到不同分区，顺序性就被破坏了，所以提前规划好分区数很重要。具体设置多少没有标准答案，但可以按目标吞吐量估算。假设每个分区能支撑每秒10MB，你预期每秒需要100MB，那分区数至少10个。还要预留一定的增长空间，比如再翻一倍到20个，但分区过多也会增加Broker的元数据负担和文件句柄数，合理区间要结合机器能力和监控数据来定。

5.4 常用监控工具

线上必须盯监控，否则出了事只能靠猜。最基础的是查看Kafka的JMX指标，可以通过kafka-run-class.sh kafka.tools.JmxTool抽取，也可以直接用Prometheus加JMX exporter采集。社区有一套广泛使用的Kafka监控体系，包括Kafka Exporter、Prometheus和Grafana，能画出Broker的入站出站流量、分区副本状态、消费滞后量等核心指标。消费滞后（Consumer Lag）是最值得盯的指标，它表示消费者当前偏移量和日志末尾偏移量的差距。滞后持续上涨说明消费能力跟不上生产速度，迟早会积压。

如果没有完整的监控体系，也可以用命令行应急：

bin/kafka-consumer-groups.sh --bootstrap-server localhost:9092 \ --group demo-group --describe

这个命令会列出该组的消费者和各个分区的当前偏移量、日志末尾偏移量以及滞后量，排查消息积压时非常有用。

6. 生产现场常见的坑与排查思路

6.1 消息积压怎么排查

消息积压是最常见的问题，现象就是消费滞后越来越大。排查思路按下面几步走：

1. 先看消费方日志，是不是有大量的消费异常。比如反序列化报错，这说明某条消息格式有问题，消费者处理不了，卡在那批消息上一直重试，后面的消息全部积压。
2. 再看消费方的耗时指标。如果单条消息处理耗时从10ms变成1秒，说明下游依赖变慢了，比如数据库慢查询、外部接口超时。这种时候加消费者线程是治标，得先把下游瓶颈找到。
3. 看消费者组内成员数。如果之前有3个消费者在跑，现在变成1个了，很可能是某个消费者被踢出组了，触发重平衡失败，分区没有被重新消费。检查消费者的心跳线程和网络稳定性。

处理积压的应急手段通常是临时增加消费者数，但要注意分区数上限，消费者数超过分区数没有意义。如果分区数不够，就只能临时写一个“脑洞”方案：比如用一个消费者把积压消息快速转发到一个分区数更多的临时主题，再起多个消费者消费临时主题，处理完后再回流。这操作看起来绕，但在紧急情况下确实有效。

6.2 重复消费与顺序性问题

重复消费是分布式系统的常态，不是Bug，而是语义设计如此。只要做到“至少一次”投递，就会因为消费者处理成功后提交偏移量之前发生宕机，重启后重新消费同一条消息。应对方法就是消费者端做幂等。

幂等的惯用方案是维护一张“已处理消息ID”表，处理前先查，处理时用数据库唯一键去重，或者把结果写入带唯一约束的目标表。不管用哪种，核心是找到一个业务上唯一的标识来做去重，比如订单号、事件ID。作为架构设计者，不要把“消息系统保证不重复”当成依赖，所有写下游的消费者都要假设“我会收到重复消息”。

顺序性问题的根源在于Kafka只保证分区内有序。跨分区、跨重试都可能导致乱序。如果业务要求顺序，有两个必须遵守的原则：第一，按业务主键发送消息，保证同一主键进入同一分区；第二，生产者把重试相关的参数配置好，避免重试导致同一主键的消息在失败后跨到其他位置。消费者则要尽量用单线程消费同一个分区，如果内部用线程池，会打破消息顺序。并发和顺序不可兼得，必须想清楚哪个对业务更重要。

6.3 磁盘与日志保留策略

Broker上的日志就是消息落地文件，Kafka不是把每条消息都单独存一个文件，而是按照分区和分段（Segment）来存储。每个分区对应一个目录，目录下有多个.log段文件，每个段有固定大小（默认1GB），消息顺序追加到当前段中，写满后滚动到新段。删除旧消息时，也是把整个段文件删除，不是去消息文件里抠单条数据，所以删除效率很高。

log.retention.hours控制消息保留时间，默认是168小时，也就是7天。如果你的业务要回溯几天甚至几周的数据，可以按需求调整，但要注意磁盘空间。你可以先估算消息日增量，比如每天100GB，想保留30天，那至少预留3TB以上的磁盘。Kafka的磁盘不是越大越好，因为一旦磁盘写满Broker会进入只读状态，生产者消息写不进去，消费者还能消费，但整个集群基本不可用。生产上一定要做好磁盘空间告警，保留策略和磁盘大小要一起看，缺一不可。

段文件的索引也是常见的排查点。Kafka会为每段日志建立稀疏索引，用于快速定位偏移量附近的消息。如果日志文件损坏，消费者在读取某个偏移量时会抛出异常，可以先通过kafka-run-class.sh kafka.tools.DumpLogSegments检查日志段是否可读。

6.4 元数据中的坑：controller和zookeeper

在ZooKeeper模式下的Kafka集群，Controller是一个核心角色。Controller负责分区副本的Leader选举、分区分配、主题管理等元数据操作。多Broker的集群里，Controller是多个Broker中的一个，由ZooKeeper临时节点协调选出。Controller挂了或者网络异常，会自动重新选举，选举期间不提供元数据变更服务，但已有的生产消费通常不受影响。

有段时间我遇到过一种诡异现象：主题创建很慢，偶尔报TimeoutException，但生产消费消息又正常。排查到最后发现是ZooKeeper节点IO延迟很高，Controller和ZooKeeper之间的会话超时，频繁触发Controller重选举。所以维护ZooKeeper模式下的Kafka，需要把ZooKeeper的节点性能看得和Kafka本身一样重，不能因为是“元数据存储”就掉以轻心。

Kafka 3.x开始KRaft模式逐渐成熟，由Kafka自身通过日志复制管理元数据，不再依赖ZooKeeper。新版集群建议评估迁移到KRaft，架构会简化很多，不过生产迁移前一定要做好充分测试。目前存量系统还大量跑在ZooKeeper上，无论你在哪个环境，理解Controller选举和ZooKeeper的角色对排查集群级故障都很有必要。

结尾：说说我自己的体会

Kafka入门其实不难，半天时间就能跑通基本流程，难点在于后续维护和调优。我见过不少系统，表面看Kafka集群正常，生产者和消费者也没报错，但消息就在某个角落里悄悄积压，等业务方发现时已经晚了。所以如果你问我最想分享什么经验，我第一个想到的就是：一定要从第一天就配好消息积压监控，消费滞后量是比Broker负载更需要关注的指标。第二个经验是，所有关于“消息会不会丢”和“会不会重复”的讨论，都必须落到一个具体参数配置和消费方式上，不要停留在模糊的“应该没问题”。第三个经验是，Kafka生态很大，初学阶段不要急着把Streams、Connect都铺上来，先把主题、分区、副本、偏移量、消费者组这些核心概念在心里扎下根，再逐步往外扩。很多人觉得Kafka复杂，不是因为东西多，而是因为没把基础模型和实际业务对应起来。如果你能把文章里这些内容亲手操作一遍，我相信你离“精通”这个词就不远了。