1. 为什么说 Kafka 是后端开发的必修课刚入行那会儿我对消息队列的理解就停留在“解耦”和“异步”两个词上面试能背出“削峰填谷”四个字就算过关。直到有一次线上事故上游服务瞬间涌入几十万条请求数据库连接池直接被打满整个交易链路雪崩。事后复盘团队里一位老哥说了句让我记到现在的话“你缺的不是加机器是缺一个能扛住洪峰的缓冲带。”那个缓冲带就是 Kafka。Kafka 到底是什么用最直白的话讲它是一个分布式的、基于发布订阅模式的消息队列系统。你可以把它想象成一个超级能装的传送带生产者往传送带一头扔包裹消费者从另一头取包裹传送带本身还能把包裹分门别类存到不同轨道上并且保留很长时间不丢。它解决的问题非常具体——当系统上下游处理速度不匹配、当多个服务需要同一份数据、当流量突然暴涨需要缓冲时Kafka 就是那个稳住局面的中间层。这篇内容适合谁看如果你是一个刚接触后端开发不久、听说过 Kafka 但一直没敢下手的开发者或者你已经在项目里用到了 Kafka 但只会复制粘贴配置、出了事不知道怎么排查那这篇就是写给你的。我会从核心概念讲到环境搭建从代码实操讲到线上避坑尽量把每个“为什么”都讲透。不堆砌术语不甩官方文档就按一个踩过坑的从业者的思路来。需要提前说明的是Kafka 的版本迭代比较快我下面涉及的操作和参数基于 3.x 版本的常见实践如果你用的是更早的版本部分命令和配置项会有差异注意对照官方文档做适配。另外文中所有示例代码和配置都经过本地验证你可以直接抄作业但生产环境的参数一定要根据自己的业务量级做调整别照搬。2. 核心概念拆解别被术语吓住2.1 Topic、Partition、Offset 到底怎么理解Kafka 里最核心的三个概念就是 Topic、Partition 和 Offset。很多人第一次看官方文档就被这三个词绕晕了我用一个生活场景给你串起来。假设你住在一个大型小区小区门口有一排快递柜。每个快递柜有一个编号比如 A 柜、B 柜、C 柜。所有寄给这个小区的快递都会根据收件人楼栋被分配到不同的柜子里。这里的“小区”就是一个Topic也就是消息的逻辑分类比如“订单消息”“日志消息”“支付消息”各是一个 Topic。每个快递柜就是Partition也就是 Topic 的物理分片。为什么要有多个柜子因为一个柜子容量有限多个柜子可以并行存取吞吐量就上去了。而每个快递在柜子里的格口编号就是Offset它是一个单调递增的序号标记这条消息在 Partition 里的位置。这个模型解释了几个关键设计。第一Kafka 的吞吐量之所以高是因为 Partition 可以分布在不同的机器上生产者和消费者可以同时读写多个 Partition。第二Kafka 只能保证同一个 Partition 内消息有序跨 Partition 不保证全局有序。这就像 A 柜和 B 柜的快递谁先到谁后到没有必然关系但同一个柜子里的格口是按顺序排列的。第三Offset 由消费者自己维护这意味着消费者可以重复消费也可以跳过某些消息灵活性很高但也带来了重复消费的风险。注意很多新手会问“一个 Topic 到底设几个 Partition 合适”。我的经验是如果只是本地开发测试1 个就够了生产环境从 3 到 6 个起步然后根据消费者线程数和吞吐量逐步调整。Partition 数量只能增加不能减少所以一开始别设太多否则后期管理成本很高。2.2 Producer、Consumer、Broker 的角色分工理解了存储模型再来看参与角色。Producer就是往 Kafka 发消息的一方比如你的订单服务在创建订单后往“订单创建”这个 Topic 发一条消息。Consumer是从 Kafka 读消息的一方比如你的库存服务订阅了这个 Topic收到消息后去扣减库存。Broker是 Kafka 的服务端节点一个 Kafka 集群由多个 Broker 组成每个 Broker 负责存储一部分 Partition 的数据。这里有个容易混淆的点Consumer 和 Consumer Group 的关系。一个 Consumer Group 可以包含多个 Consumer 实例它们共同消费一个 Topic 的所有 Partition。Kafka 的规则是同一个 Consumer Group 内一个 Partition 只能被一个 Consumer 消费但不同的 Consumer Group 可以同时消费同一个 Partition。这个设计非常巧妙——它既实现了负载均衡多个 Consumer 分摊 Partition又实现了广播多个 Group 各收一份。举个例子你的“用户注册”Topic 有 3 个 Partition。你有一个“发欢迎邮件”的 Consumer Group里面有 3 个实例正好一人负责一个 Partition并行处理。同时你还有一个“数据分析”的 Consumer Group里面只有 1 个实例那它就要消费全部 3 个 Partition。两个 Group 互不影响各自维护自己的 Offset。这就是 Kafka 作为“发布订阅”系统的核心能力。2.3 Replica、ISR、Leader 选举的底层逻辑前面说的都是好消息但分布式系统绕不开一个问题如果某台 Broker 挂了数据会不会丢Kafka 的答案是Replica机制。每个 Partition 可以有多个副本其中一个叫Leader负责处理所有读写请求其他的叫Follower只负责同步 Leader 的数据。当 Leader 所在的 Broker 宕机时Kafka 会从 Follower 中选出一个新的 Leader保证服务不中断。那怎么判断哪些 Follower 有资格当 Leader这就引出了ISR的概念全称是 In-Sync Replica也就是“保持同步的副本集合”。只有那些跟得上 Leader 进度的 Follower 才会被放进 ISR 列表。如果某个 Follower 落后太多它会被踢出 ISR直到追上进度再重新加入。当 Leader 挂掉时Kafka 只会从 ISR 里选新 Leader这样能最大程度保证数据不丢。这里涉及一个关键参数acks。Producer 发消息时可以指定acks0、acks1或acksall。acks0表示发出去就不管了速度最快但可能丢消息acks1表示 Leader 写入成功就返回如果 Leader 刚写完就挂了Follower 还没同步消息还是会丢acksall表示所有 ISR 里的副本都写入成功才返回最安全但延迟最高。生产环境里涉及钱和订单的消息我强烈建议用acksall配合min.insync.replicas2这样即使挂一台 Broker 也不会丢数据。提示min.insync.replicas这个参数经常被忽略。它表示 ISR 里至少要有几个副本Producer 才能写入成功。如果设成 2而 ISR 里只剩 1 个副本写入就会直接失败。这看起来是“降低可用性”但实际上是防止你在数据安全上裸奔。我见过太多团队为了追求高可用把acks设成 1结果机房断电时丢了一批关键消息追都追不回来。3. 环境搭建从零把 Kafka 跑起来3.1 单机环境快速部署本地开发最省事的方式是用 Docker 跑一个单节点 Kafka。别一上来就折腾集群单机先把基本操作跑通理解清楚再扩展。下面是我常用的docker-compose.yml配置基于 KRaft 模式Kafka 3.x 之后推荐的方式不再依赖 ZooKeeper。version: 3 services: kafka: image: bitnami/kafka:3.6 container_name: kafka-local ports: - 9092:9092 environment: - KAFKA_CFG_NODE_ID1 - KAFKA_CFG_PROCESS_ROLESbroker,controller - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS1kafka:9093 - KAFKA_CFG_LISTENERSPLAINTEXT://:9092,CONTROLLER://:9093 - KAFKA_CFG_ADVERTISED_LISTENERSPLAINTEXT://localhost:9092 - KAFKA_CFG_CONTROLLER_LISTENER_NAMESCONTROLLER - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAPCONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT - KAFKA_CFG_LOG_DIRS/bitnami/kafka/data - ALLOW_PLAINTEXT_LISTENERyes volumes: - kafka_data:/bitnami/kafka volumes: kafka_data:这份配置里几个关键点解释一下。KAFKA_CFG_PROCESS_ROLES设成broker,controller表示这个节点同时承担 Broker 和 Controller 的角色单机模式下这样最省资源。KAFKA_CFG_CONTROLLER_QUORUM_VOTERS是 KRaft 模式的选举配置单节点就写自己。KAFKA_CFG_ADVERTISED_LISTENERS特别重要它告诉客户端“你应该用哪个地址连我”如果这里写错了本地能连上但远程连不上是新手最常见的坑之一。启动命令就一行docker-compose up -d等几秒钟用docker logs kafka-local看到 “Kafka Server started” 就说明起来了。接下来可以进容器创建第一个 Topicdocker exec -it kafka-local kafka-topics.sh \ --bootstrap-server localhost:9092 \ --create \ --topic order-created \ --partitions 3 \ --replication-factor 1创建完可以用--describe看一下详情确认 Partition 数量和副本数符合预期。3.2 生产环境集群规划要点单机跑通之后如果你要上生产就得考虑集群了。生产环境的 Kafka 集群规划我总结下来主要看三个维度磁盘、网络、副本策略。磁盘方面Kafka 是顺序写磁盘的所以机械硬盘也能扛住很高的吞吐但如果你追求极致性能SSD 肯定更好。更重要的是磁盘容量规划——Kafka 默认消息保留 7 天你要根据每天的消息量和平均消息大小估算总存储。比如每天 1 亿条消息平均 1KB那就是 100GB 一天7 天就是 700GB再算上副本因子 3实际需要 2.1TB。这还没算索引文件和日志文件的开销所以一般要再留 30% 的余量。网络方面Kafka 的瓶颈往往在网卡带宽上。一个 Broker 如果承担大量 Partition 的读写千兆网卡很容易打满。生产环境建议至少万兆网卡并且 Broker 之间最好在同一机房内网跨机房同步延迟会严重影响 ISR 的稳定性。副本策略上replication.factor建议设成 3min.insync.replicas设成 2。这样你最多容忍一台 Broker 挂掉而不影响写入。如果设成 2 和 1虽然写入更顺畅但挂一台就丢数据风险陡增。另外unclean.leader.election.enable一定要设成false这个参数允许非 ISR 副本当选 Leader虽然提高了可用性但会丢数据生产环境绝对不能开。3.3 常用命令行工具速查Kafka 自带了一套命令行工具日常运维和排查问题离不开它们。我把最常用的几个整理成表格方便你随时查。操作命令说明创建 Topickafka-topics.sh --create --topic xxx --partitions 3 --replication-factor 3 --bootstrap-server xxx分区数和副本数按需调整查看 Topic 列表kafka-topics.sh --list --bootstrap-server xxx列出所有 Topic查看 Topic 详情kafka-topics.sh --describe --topic xxx --bootstrap-server xxx重点看 ISR 和 Leader 分布生产消息kafka-console-producer.sh --topic xxx --bootstrap-server xxx回车分隔每条消息消费消息kafka-console-consumer.sh --topic xxx --from-beginning --bootstrap-server xxx--from-beginning从头消费查看消费者组kafka-consumer-groups.sh --list --bootstrap-server xxx列出所有消费组查看消费进度kafka-consumer-groups.sh --describe --group xxx --bootstrap-server xxx看 LAG 判断是否有积压删除 Topickafka-topics.sh --delete --topic xxx --bootstrap-server xxx需要delete.topic.enabletrue这里面我重点说下--describe看消费组进度的用法。输出里有个LAG列表示“还有多少条消息没消费”。如果 LAG 持续增长说明消费者处理速度跟不上生产速度要么加消费者实例要么优化消费逻辑。如果 LAG 突然变成负数或者异常大可能是 Offset 被重置了要赶紧查原因。注意kafka-console-consumer.sh默认从最新位置开始消费如果你要验证历史消息记得加--from-beginning。但生产环境慎用这个参数万一 Topic 数据量巨大会把消费者压垮。4. 代码实操Spring Boot 集成 Kafka 完整流程4.1 依赖引入与基础配置Java 生态里集成 Kafka 最顺手的方式就是 Spring Boot 加spring-kafka。先看依赖Maven 里加这么一段dependency groupIdorg.springframework.kafka/groupId artifactIdspring-kafka/artifactId version3.1.0/version /dependency版本号根据你的 Spring Boot 版本选一般跟 Spring Boot 主版本对齐就行。加完依赖接下来是application.yml配置spring: kafka: bootstrap-servers: localhost:9092 producer: key-serializer: org.apache.kafka.common.serialization.StringSerializer value-serializer: org.apache.kafka.common.serialization.StringSerializer acks: all retries: 3 properties: enable.idempotence: true consumer: group-id: order-service-group auto-offset-reset: earliest key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.apache.kafka.common.serialization.StringDeserializer enable-auto-commit: false listener: ack-mode: manual这段配置里有几个点值得展开。acks: all配合enable.idempotence: true是生产者的黄金组合前者保证消息写入所有 ISR 副本后者保证重试时不会产生重复消息。auto-offset-reset: earliest表示当消费者组没有初始 Offset 时从最早的消息开始消费这在开发阶段很有用但生产环境要谨慎避免突然消费大量历史消息。消费者这边enable-auto-commit: false加上ack-mode: manual是我强烈推荐的组合。自动提交 Offset 虽然省事但会在消息还没处理完就提交一旦处理过程中服务挂了消息就丢了。手动提交虽然多写几行代码但能保证“处理成功再提交”数据可靠性高得多。4.2 生产者发送消息的三种方式Spring Kafka 的KafkaTemplate封装了发送消息的各种方法常用的有三种发后即忘、同步发送、异步发送。发后即忘就是直接调send()不管结果kafkaTemplate.send(order-created, orderId, orderJson);这种方式吞吐量最高但消息丢了也不知道。适合日志采集这类对可靠性要求不高的场景。同步发送是调send()之后拿返回的Future调get()try { SendResultString, String result kafkaTemplate .send(order-created, orderId, orderJson) .get(3, TimeUnit.SECONDS); log.info(发送成功, offset{}, result.getRecordMetadata().offset()); } catch (Exception e) { log.error(发送失败, e); // 这里可以做重试或落库补偿 }同步发送能拿到发送结果失败可以立即处理但每次都要等 Broker 确认吞吐量会下降。适合订单、支付这类关键消息。异步发送是传一个回调kafkaTemplate.send(order-created, orderId, orderJson) .whenComplete((result, ex) - { if (ex null) { log.info(发送成功, offset{}, result.getRecordMetadata().offset()); } else { log.error(发送失败, ex); } });异步发送兼顾了吞吐量和可靠性是我在大多数场景下的首选。回调里可以做失败记录后续用定时任务补偿。提示不管用哪种方式都建议给send()指定 key。Kafka 会根据 key 的哈希值决定消息进哪个 Partition同一个 key 的消息会进同一个 Partition从而保证局部有序。比如用订单 ID 做 key同一个订单的所有状态变更消息就会有序消费不会出现“先收到已支付再收到已创建”的乱序问题。4.3 消费者监听与手动提交 Offset消费者这边用KafkaListener注解就能快速起一个监听Component public class OrderConsumer { KafkaListener(topics order-created, groupId order-service-group) public void consume(ConsumerRecordString, String record, Acknowledgment ack) { try { log.info(收到消息: topic{}, partition{}, offset{}, key{}, value{}, record.topic(), record.partition(), record.offset(), record.key(), record.value()); // 业务处理逻辑 processOrder(record.value()); // 处理成功手动提交 offset ack.acknowledge(); } catch (Exception e) { log.error(处理失败, offset{}, record.offset(), e); // 不提交 offset消息会被重新消费 } } }这里的关键是Acknowledgment参数它只有在ack-mode: manual时才会注入。处理成功调acknowledge()提交 Offset处理失败就不提交Kafka 会在下一次拉取时重新投递这条消息。但这里有个坑如果这条消息本身有问题比如格式错误导致反序列化失败那它会一直重试阻塞整个 Partition 的消费。所以生产环境一定要配死信队列把反复失败的消息转移到另一个 Topic避免卡死。死信队列的配置方式是在application.yml里加spring: kafka: listener: ack-mode: manual producer: properties: max.block.ms: 5000然后在监听器里用KafkaListener的errorHandler或者自己捕获异常后转发到死信 Topic。这块展开能写很多核心思路就是“失败超过 N 次就转移别让它无限重试”。4.4 消息序列化与反序列化的选择前面示例用的都是字符串序列化简单直接。但实际项目里消息体往往是对象这时候就需要 JSON 序列化或者 Avro、Protobuf 这类二进制序列化。JSON 序列化最通用用JsonSerializer和JsonDeserializer就行spring: kafka: producer: value-serializer: org.springframework.kafka.support.serializer.JsonSerializer consumer: value-deserializer: org.springframework.kafka.support.serializer.JsonDeserializer properties: spring.json.trusted.packages: com.example.dto注意spring.json.trusted.packages这个配置不配的话反序列化会报安全异常。这是 Spring Kafka 的一个安全机制防止恶意类被反序列化。Avro 和 Protobuf 的优势是体积小、序列化快而且 Avro 配合 Schema Registry 可以做 schema 演进非常适合大型项目。但引入 Schema Registry 会增加运维复杂度小团队用 JSON 就够了。我的建议是如果消息体不大、团队规模不大JSON 完全够用如果消息量极大、对带宽敏感再考虑 Avro 或 Protobuf。5. 线上踩坑实录与排查技巧5.1 消息重复消费的根因与解法重复消费是 Kafka 使用中最常见的问题没有之一。根因通常有三个消费者处理成功但提交 Offset 失败、消费者 Rebalance 导致 Offset 回退、生产者重试导致消息重复发送。第一个场景最典型。你处理完消息调ack.acknowledge()但这时候网络抖动提交请求没到 Broker消费者就挂了。下次重启Kafka 发现 Offset 没更新就把那条消息再发一遍。解法是业务逻辑做幂等比如用订单 ID 做唯一索引重复插入直接忽略。第二个场景是 Rebalance。当消费者组里有新实例加入或旧实例离开Kafka 会重新分配 Partition。在 Rebalance 过程中已经拉取但还没提交 Offset 的消息会被重新分配给其他消费者导致重复消费。解法是尽量缩短 Rebalance 时间比如调大session.timeout.ms和max.poll.interval.ms同时确保单次poll拉取的消息不要太多处理时间别超过max.poll.interval.ms。第三个场景是生产者重试。如果acksall且没开幂等Producer 发送超时后重试Broker 可能已经写入成功就会产生重复消息。解法就是前面说的enable.idempotence: true它会给每条消息分配一个序列号Broker 根据序列号去重。注意幂等生产者只能保证单 Partition 内不重复跨 Partition 还是可能重复。所以业务层的幂等设计是最后一道防线不能省。5.2 消费积压的紧急处理方案消费积压的表现是LAG持续增长消息越堆越多。紧急处理分三步走。第一步先看消费者是不是挂了。用kafka-consumer-groups.sh --describe看消费者组状态如果某个 Partition 没有活跃消费者说明有实例掉线了。赶紧重启或扩容。第二步如果消费者都在但处理速度跟不上先临时扩容消费者实例。注意消费者实例数不能超过 Partition 数多出来的实例会闲置。如果 Partition 已经满了那就只能优化消费逻辑比如把单条处理改成批量处理或者把耗时操作异步化。第三步如果积压太多短期处理不完可以考虑重置 Offset 跳过一部分消息。用kafka-consumer-groups.sh --reset-offsets命令把 Offset 跳到最新位置。但这意味着中间的消息永久丢失只适合那些可以容忍丢消息的场景比如日志采集。订单类消息绝对不能这么干。我自己的经验是预防积压比处理积压重要得多。上线前一定要做压测估算消费者的 TPS然后按峰值流量的 1.5 倍配置消费者实例。同时监控 LAG 指标超过阈值就告警别等积压了几百万条才发现。5.3 常见异常速查表异常现象可能原因排查方向解决方案生产者发送超时Broker 负载高、网络延迟、acksall等待副本看 Broker 的 CPU 和网络指标增加 Broker、调大timeout.ms、检查 ISR 是否收缩消费者反复重平衡处理时间超过max.poll.interval.ms看日志里有没有 Rebalance 记录调大该参数、减少单次拉取数量、优化处理逻辑Offset 提交失败消费者被踢出组、网络问题看消费者日志和 Broker 日志检查session.timeout.ms、确保心跳线程正常消息乱序生产者未指定 key、跨 Partition确认消息是否同一 key用业务主键做 key保证同 key 进同 Partition磁盘写满消息保留时间过长、消息量突增看 Broker 磁盘使用率调小log.retention.hours、清理过期数据、扩容磁盘反序列化失败消息格式不匹配、schema 变更看消费者异常堆栈检查生产者和消费者的序列化配置是否一致这张表里的每一行都是我或身边同事真实踩过的坑。特别是“消费者反复重平衡”这一条新手很容易忽略max.poll.interval.ms这个参数。它的默认值是 5 分钟如果你的消费逻辑里有调用外部接口、写数据库等耗时操作很容易超过这个时间然后消费者就被判定为“死了”触发 Rebalance。解法要么是调大这个参数要么是把耗时操作放到线程池里异步处理让poll循环尽快返回。5.4 监控指标与告警配置建议Kafka 的监控指标很多但核心的就那么几个。我按重要性排个序UnderReplicatedPartitions、ActiveControllerCount、RequestHandlerAvgIdlePercent、MessagesInPerSec、BytesInPerSec、BytesOutPerSec、ConsumerLag。UnderReplicatedPartitions是最关键的它表示有多少 Partition 的副本数不足。如果这个值大于 0说明有 Broker 挂了或者同步跟不上数据丢失风险很高必须立即处理。ActiveControllerCount在集群里应该始终为 1如果为 0 说明没有 Controller集群无法正常工作如果大于 1 说明出现了脑裂非常危险。ConsumerLag就是前面说的消费积压建议按 Topic 和消费组分别配置告警阈值。比如 LAG 超过 10 万条持续 5 分钟就告警。这个阈值根据你的业务容忍度来定没有统一标准。监控工具方面开源的有 Kafka Exporter 配合 Prometheus 和 Grafana商业的有 Confluent Control Center 等。我建议至少把 Prometheus 加 Grafana 这套搭起来成本不高但能救命。Grafana 上有现成的 Kafka 仪表盘模板导入就能用省得自己画图。提示告警不要只配一个阈值要分级别。比如 LAG 超过 1 万是 Warning超过 10 万是 Critical。Warning 级别先观察Critical 级别直接打电话。另外告警要配“恢复通知”不然问题解决了你还不知道一直盯着看。6. 性能调优的几个关键参数6.1 生产者端吞吐量优化生产者端提升吞吐量的核心思路是“攒一批再发”。Kafka Producer 有两个参数控制批量行为batch.size和linger.ms。batch.size是每个 Partition 的批次大小默认 16KBlinger.ms是发送前等待的时间默认 0也就是来一条发一条。把linger.ms调到 5 到 10 毫秒batch.size调到 64KB 或 128KB吞吐量能提升好几倍。代价是消息延迟增加了这几毫秒。对于大多数业务来说几毫秒的延迟完全可以接受但吞吐量提升是实打实的。还有一个参数是compression.type默认不压缩。改成lz4或snappy能显著减少网络传输和磁盘占用CPU 开销也不大。我实测下来lz4在吞吐量和压缩比之间平衡得最好推荐优先用。6.2 消费者端拉取策略调整消费者端的关键参数是fetch.min.bytes和max.poll.records。fetch.min.bytes表示一次拉取至少要有多少数据才返回默认 1 字节也就是来一条拉一条。调大到 1KB 或 10KB能减少网络往返次数提升吞吐。max.poll.records表示单次poll最多返回多少条消息默认 500。如果你的处理逻辑比较慢把这个值调小比如 100能降低单次处理时间减少 Rebalance 风险。另外max.partition.fetch.bytes控制每个 Partition 单次拉取的最大字节数默认 1MB。如果单条消息特别大比如超过 1MB这个参数要相应调大否则消费者会一直拉不到完整消息。但 Kafka 本身不建议单条消息超过 1MB大消息会严重影响吞吐和内存能拆就拆。6.3 Broker 端关键参数Broker 端我重点说三个参数num.network.threads、num.io.threads、log.flush.interval.messages。num.network.threads负责处理网络请求默认 3。如果 Broker 的网卡带宽很高、连接数很多可以调到 8 或 16。num.io.threads负责磁盘 IO默认 8如果磁盘是 SSD 且吞吐量高可以调到 16 或 32。这两个参数调优的效果很明显但别盲目调大要结合 CPU 核数来一般不超过 CPU 核数的两倍。log.flush.interval.messages控制多少条消息刷一次盘默认是Long.MAX_VALUE也就是完全交给操作系统刷盘。很多人担心这样会丢数据其实 Kafka 的可靠性主要靠副本机制而不是同步刷盘。强制刷盘会严重降低性能而且即使刷盘了如果磁盘坏了照样丢。所以这个参数保持默认就好别去动它。7. 从开发到生产的完整检查清单7.1 上线前的配置核对上线前我习惯对着清单过一遍避免遗漏。生产者这边确认acksall、enable.idempotencetrue、retries大于 0、compression.type已设置。消费者这边确认enable-auto-commitfalse、auto-offset-reset是latest而不是earliest、max.poll.interval.ms足够大、死信队列已配置。Topic 层面确认 Partition 数合理、replication.factor至少 3、min.insync.replicas至少 2、retention.ms符合业务需求。Broker 层面确认unclean.leader.election.enablefalse、log.retention.hours已调整、磁盘告警已配置。这份清单看起来琐碎但每一条背后都是血泪教训。我见过因为auto-offset-reset配成earliest导致上线后瞬间消费几百万条历史消息把数据库打挂的也见过因为replication.factor1导致 Broker 挂掉后数据全丢的。花十分钟核对能省十天排查。7.2 灰度发布与回滚策略Kafka 相关的变更灰度发布特别重要。比如你要改消费者的处理逻辑不要一次性全量发布先发一台实例观察 LAG 和错误日志确认没问题再逐步扩大。如果发现异常立即回滚Kafka 的 Offset 机制能保证回滚后从上次提交的位置继续消费不会丢消息。Topic 的变更也要灰度。比如增加 Partition 数虽然 Kafka 支持在线增加但增加后消息的路由会变化可能影响依赖 key 有序性的业务。建议在低峰期操作并且提前通知上下游。回滚策略上我建议每次发布都准备好“一键回滚”的脚本或流程。Kafka 消费者回滚相对简单停掉新版本、启动旧版本就行。但要注意如果新版本已经提交了 Offset旧版本会从新 Offset 继续消费不会重复处理已提交的消息。所以如果新版本的处理逻辑有 bug 导致数据写错了回滚并不能自动修复数据还需要额外的数据修复方案。7.3 容量规划与扩容时机容量规划的核心是估算三个指标消息生产速率、消息大小、保留时间。生产速率乘以消息大小就是每天的存储增量再乘以保留天数就是总存储需求。加上副本因子和索引开销就是实际磁盘需求。扩容时机怎么判断看两个信号一是磁盘使用率持续超过 70%二是UnderReplicatedPartitions频繁大于 0。前者说明存储快满了后者说明现有 Broker 扛不住副本同步的压力了。这两个信号出现任何一个就该考虑加 Broker 了。加 Broker 之后别忘了把部分 Partition 迁移到新节点上否则新 Broker 闲着老 Broker 继续扛压。迁移用kafka-reassign-partitions.sh工具先生成迁移计划再执行最后验证。迁移过程会占用网络和磁盘 IO建议在低峰期做并且限速避免影响正常读写。8. 我个人在实际操作中的几点体会写了这么多最后分享几个我自己的真实体会不一定对但都是踩坑换来的。第一个体会是Kafka 的“简单”是假象。它的 API 确实简单几行代码就能收发消息但背后的副本机制、ISR、Rebalance、幂等性每一个展开都是一本书。我见过太多人用 Kafka 只用了个皮毛出了事完全不知道从哪查。所以我的建议是用之前至少把核心概念搞清楚别只会复制配置。第二个体会是监控比调优重要。很多人一上来就研究怎么调参数提升吞吐量但连基本的监控都没配。结果线上出了问题连是生产者慢了还是消费者慢了都不知道。先把 Prometheus 和 Grafana 搭起来把核心指标盯住再谈调优。第三个体会是幂等设计是底线。不管你用acksall还是开了幂等生产者业务层的幂等都不能省。因为分布式系统里网络分区、节点故障、Rebalance 这些事一定会发生消息重复几乎不可避免。用唯一索引、状态机、去重表随便哪种方式一定要有。第四个体会是别把 Kafka 当数据库用。Kafka 的消息保留时间有限默认 7 天虽然可以调长但它不是用来做长期存储的。需要长期保存的数据消费后要落到数据库或对象存储里。我见过有人把 Kafka 当唯一存储结果 retention 到期数据被清理了哭都来不及。最后一个体会是社区和文档是最好的老师。Kafka 的官方文档写得非常详细很多参数都有解释和推荐值。遇到问题先查官方文档再查社区 issue最后再问人。我很多解决方案都是从官方文档的某个角落或者社区的一个 issue 里找到的比到处问人高效得多。这个内容后续还可以这样扩展比如深入讲一下 Kafka Streams 做流处理或者讲一下 Kafka Connect 做数据同步再或者讲一下 Exactly-Once 语义的实现原理。每一个方向都够写一篇长文等有机会再展开。
