Kafka 这几年几乎成了后端简历上的标配出去面试十家有八家都会问。但真要把它讲清楚很多人又容易卡在“能用但说不透”的阶段环境能搭起来生产消费能跑通可一旦被问底层原理、消息可靠性、延迟怎么降就支支吾吾了。这篇就当是一份 Kafka 教程性质的总结把核心原理、部署落地、高频考点和实际排查串在一起尽量用大白话讲逻辑而不是堆概念。看的时候不用急着背先跟着链路走一遍你会发现 Kafaka 的设计其实是一条很顺的因果链。1. 先把 Kafka 是什么讲透从工作模型到选型场景1.1 Kafka 的核心角色和消息流转模型Kafka 的本质是一个分布式提交日志distributed commit log这个定位非常关键。传统消息队列强调“队列”消息被消费后往往就没了Kafka 更强调“日志”消息按顺序追加到分区里消费者通过 offset 记录自己读到哪读完之后消息还留在磁盘上直到超过保留时间才会被清理。Kafka 里最基本的几个角色Producer 负责把消息发到 TopicTopic 被拆成多个 Partition每个 Partition 内部是严格有序的Consumer 以消费者组Consumer Group为单位订阅 Topic一个分区只会被同一个组内的一个消费者消费保证同一分区消息处理不打架。Broker 就是承载这些 Topic 分区的服务节点一个 Kafka 集群通常由多个 Broker 组成。我比较喜欢把 Topic 想象成一个巨大的书架Partition 是这本大书里的分册消息是分册里按页号连续写的文字Consumer Group 里的每个消费者各领几本分册去读。Page 号就是这个故事里的 offset。这样的抽象能帮你后面理解很多设计为什么 Kafka 吞吐高、为什么能回放、为什么消费组增减节点会触发 rebalance。1.2 Kafka 的定位它和普通消息队列到底差在哪很多人第一反应是“Kafka 不就是个消息队列”这句话不能说错但会低估它的能力。Kafka 官方给自己的定义是“分布式事件流平台”消息队列只是它众多能力里的一部分。和 RabbitMQ、ActiveMQ 这类传统 MQ 相比最明显的差异是消息留存模型。传统 MQ 更适合点对点的任务分发消息被一个消费者拿走处理完基本就该从内存或队列里删掉。Kafka 的消息保存在磁盘上消费者只是在游标往前走所以天然支持多个消费者组各自独立消费同一份数据谁也不会影响谁。这个特性让 Kafka 在日志采集、指标监控、用户行为追踪、数据管道等场景里特别吃香。比如你有一堆埋点日志既要进实时计算又要进数仓做离线分析还可能要同步到 Elasticsearch 做检索一份数据多个组分别消费就行完全不用复制多份。正是这种“一份数据多方使用”的模型让它成为实时数仓和数据湖选型里绕不开的角色。1.3 什么时候别用 Kafka避坑聊选型的时候不能只说 Kafka 的好否则就是误导。如果你每天的流量很小比如几千条订单消息业务又要复杂路由、死信队列、按消息维度延迟重试那 Kafka 不一定是最优解。这个体量下 RabbitMQ 或者一些云厂商的 MQ 服务可能更省心配置简单能直接满足需求。Kafka 的擅长区间是“高吞吐、多订阅、顺序追加、后续回放”代价是组件多、参数多、运维门槛高。为了每天几千条消息去维护一套 Kafka 集群跟用大炮打蚊子差不多。还有一类场景比如 RPC 调用之间需要毫秒级的低延迟和强可靠也不建议硬上 Kafka它追求的是吞吐优先单条消息延迟虽然不高但整体架构和参数调优并不轻松。一句话技术选型先看场景是否匹配再看团队能不能接住运维负担最后才轮到性能对比。2. 环境准备Kafka 下载、安装、集群、可视化工具一条龙2.1 下载与单机安装先把配置里最关键的两个地方盯住网上关于 Kafka 下载安装的教程非常多但很多人照做还是起不来问题往往不是命令不对而是对配置理解不够。先去 Apache Kafka 官网或国内镜像下载二进制压缩包版本建议选 3.5 以上毕竟新的 KRaft 模式越来越成熟。下载后解压如果只跑单机核心是修改 config/server.properties。Kafka 3.x 以后支持两个模式传统 ZooKeeper 模式和 KRaft 模式。KRaft 模式不需要额外起 ZooKeeper节点自己就是 Controller Candidate部署和维护都简单不少。新项目我比较推荐直接用 KRaft。单机示范配置可以参考process.rolesbroker,controller node.id1 controller.quorum.voters1localhost:9093 listenersPLAINTEXT://:9092,CONTROLLER://:9093 inter.broker.listener.namePLAINTEXT advertised.listenersPLAINTEXT://localhost:9092 controller.listener.namesCONTROLLER log.dirs/tmp/kraft-combined-logs第一遍跑 Kafka 的人最容易栽在两个地方。一个是 Java 版本太低Kafka 3.x 要求 JDK 8 以上推荐 11 或 17另一个是 advertised.listeners 配置不对后续客户端连接会出现各种连不上。配置完成后先执行分区格式化命令KRaft 模式需要先格式化存储目录再启动服务顺序搞错也会启动失败。启动成功后再用 kafka-topics.sh 创建第一个 topic用 kafka-console-producer.sh 和 kafka-console-consumer.sh 验证收发环境就算通了。2.2 Kafka 集群安装三个节点这样配置才能保证高可用生产环境基本不会单节点裸奔Kafka 的高可用依赖副本机制只有多 Broker 才能形成副本。集群节点数量一般至少 3 个才能容忍挂掉一个节点并保证多数副本仍然存活。如果继续用 KRaft 模式每个节点配置文件类似但 node.id 不能重复controller.quorum.voters 要写全三个节点的地址和端口。比如三台机器 192.168.1.11、192.168.1.12、192.168.1.13每个节点配置里都要写process.rolesbroker,controller node.id1 controller.quorum.voters1192.168.1.11:9093,2192.168.1.12:9093,3192.168.1.13:9093 listenersPLAINTEXT://192.168.1.11:9092,CONTROLLER://192.168.1.11:9093 advertised.listenersPLAINTEXT://192.168.1.11:9092 log.dirs/data/kraft-combined-logs需要注意advertised.listeners 要写客户端真正能访问到的地址。如果 Broker 之间走内网 IP客户端也在内网就写内网 IP如果有域名或公网映射就写对应的外部地址。很多“集群起来了但客户端连不上”的情况基本都是这里不一致导致的。集群启动后建议创建 topic 时把副本因子设成 2 或 3比如--replication-factor 3 --partitions 3。同时把min.insync.replicas配置为 2配合生产端 acksall 使用能避免 Leader 挂掉时丢消息。想知道集群里有哪些节点在服务用kafka-metadata.sh shell或查看 metrics 都能判断。2.3 用 Docker Compose 快速起一套 Kafka很多本地开发和测试场景不想在本机装一堆依赖直接上 Docker 是最快的。但 Docker 里的 Kafka 比裸机多一层网络映射配置问题被放大所以这里单独列一节。下面是一份可用的 docker-compose.yml用的是 bitnami 镜像内置了 KRaft省掉 ZooKeeperservices: kafka: image: bitnami/kafka:3.6 container_name: kafka ports: - 9092:9092 environment: - KAFKA_CFG_NODE_ID0 - KAFKA_CFG_PROCESS_ROLEScontroller,broker - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS0kafka:9093 - KAFKA_CFG_LISTENERSPLAINTEXT://:9092,CONTROLLER://:9093 - KAFKA_CFG_ADVERTISED_LISTENERSPLAINTEXT://127.0.0.1:9092 - KAFKA_CFG_CONTROLLER_LISTENER_NAMESCONTROLLER - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAPCONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT - ALLOW_PLAINTEXT_LISTENERyes volumes: - kafka_data:/bitnami/kafka volumes: kafka_data:这组配置最关键的是KAFKA_CFG_ADVERTISED_LISTENERSPLAINTEXT://127.0.0.1:9092。因为容器内部监听的地址是:9092而宿主机端口 9092 映射到了容器的 9092所以对外宣传的地址必须用127.0.0.1:9092否则你在宿主机上的客户端访问时会拿到一个容器内部的域名或者 IP然后报Error while fetching metadata with correlation id。这个错后面 5.1 节专门讲。Docker 方式很适合本地快速验证但要记住容器重启后数据是否保留取决于 volume 是否挂载。临时测试可以不挂开发环境建议挂上持久化目录别等集群崩了才后悔。2.4 Kafka 可视化工具别再只用命令行敲了命令行在排查问题时很有用但日常看消息、看消费 lag、手动调试 topic有个图形界面会舒服很多。现在常用的 Kafka 可视化工具我整理成一张对比表格工具名称定位优点适合场景Offset Explorer原 Kafka Tool桌面客户端稳定功能全查看分区、offset、消息体很方便个人日常查看Kafka-UIprovectusWeb 工具开源支持多集群、Schema Registry、动态查看 topic团队共享、测试环境KafdropWeb 工具轻量Docker 起非常快界面简洁快速预览消息Conduktor客户端/企业体验好功能丰富但收费商业团队我的习惯是本地单个集群用 Offset Explorer 最省事团队协作看测试环境我直接部署 Kafka-UI浏览器打开就能看。注意图形工具连接 Kafka 时填的 bootstrap servers 也必须和 advertised.listeners 对上否则一样连不上。工具只是辅助重点是你脑子里对 topic、分区、offset 的模型足够清晰。3. 核心原理消息从生产到消费中间发生了什么3.1 Producer 端分区策略和批量发送为什么能提高吞吐一条消息从 Producer 发出到 Broker 落盘中间并不是“发送一条写入一条”的简单流程。Kafka 的 Producer 内部有一个消息累加器RecordAccumulator它先把很多消息攒成批次batch再由后台发送线程批量发出去。这就是 Kafka 高效的重要起点。Producer 会先经过序列化器把消息转成字节然后由分区器决定这条消息进哪个分区。分区逻辑默认是这样如果消息指定了 partition就直接用没指定但 key 不为空就对 key 做哈希取模key 也为空就用粘性分区策略尽量让一批消息集中写到一个分区减小网络开销和分区切换开销。关于批量发送有个简单的估算可以帮你理解为什么参数重要。假设每条消息 1KBbatch.size 设置为 16KB那么一个 batch 理论上能装 16 条消息。如果 linger.ms 设置为 5ms就是说最多等 5ms消息不足 batch 大小也会发送。这个设计本质是用很小的延迟换吞吐非常适合日志、埋点、指标这类允许轻微延迟的场景。如果你的业务对延迟极度敏感又想拿到高吞吐就需要结合机器规格和压测结果去调。3.2 Broker 端顺序写、页缓存和零拷贝Kafka 性能的三大支柱Kafka 之所以敢说自己能撑百万级吞吐核心在 Broker 的存储设计。很多人一听“消息落到磁盘”就觉得慢但 Kafka 做的是顺序追加写消息永远写到分区日志文件的末尾。机械硬盘随机写和顺序写的性能差距可能有一个数量级以上SSD 虽然随机写也不错但顺序写依然更稳定。另一个重要机制是页缓存。Kafka 写入时先落到操作系统页缓存由操作系统在合适时机刷到磁盘读的时候如果数据还热在页缓存里根本不用碰磁盘。这不光是省了一次 IO还绕开了 JVM 堆内存的很多烦恼所以 Kafka 默认并不建议盲目调大堆内存反而更依赖操作系统缓存。零拷贝则是读取路径的杀器。传统读文件然后发网络需要经过内核到用户态、用户态再回到内核的多次拷贝Kafka 可以用 sendfile 系统调用直接在内核态把页缓存数据发送到网卡省掉两次拷贝。面试聊到“Kafka 为什么快”把这三点串成一条因果链讲比背几个名词强得多。3.3 Consumer 端消费者组、Rebalance 和位移提交消费端的核心是消费者组和 offset 的管理。一个消费者组订阅一个 TopicTopic 的每个分区只被组内一个消费者持有这样保证分区内数据不会被同一个组重复消费。如果消费者个数大于分区数那多出来的消费者会空转这就是为什么消费能力不够时要优先看分区数。当消费者组里的成员增多或减少或者订阅的 topic 分区数变化时会触发 rebalance也就是重新分配分区。rebalance 期间消费者会暂停消费整个过程如果频繁发生就是消费者重复消费和消费延迟的常见元凶。新版 Kafka 支持 cooperative rebalance能尽量做到先分配后撤销减少阻塞时间但依然不建议用数量频繁波动的消费者。offset 是消费者消费位置的指针Kafka 老版本存在 ZooKeeper 里新版本默认提交到__consumer_offsets这个内部 topic。消费端有两个典型姿势自动提交和手动提交。自动提交省事但可能重复消费或丢消息手动提交灵活能控制确认时机。生产环境我通常建议enable.auto.commitfalse处理完消息再手动提交保证业务和 offset 相对同步。3.4 如何实现延迟 30 分钟消费Kafka 没有内置延迟队列怎么办“Kafka 如何延迟 30 分钟消费”是很多搜索里出现的高频词。先说结论Kafka 原生没有延迟队列能力它只保证按 offset 顺序投递不会因为你指定一个延迟时间就让消息 30 分钟后再出现。所以项目里碰到这种需求就要自己搭一层。最常见的方案是“延迟 topic 定时转发”。具体做法是生产者把带目标投递时间的消息发到一个内部延迟 topic这个 topic 只给一个调度服务消费调度服务每隔一定时间扫描消息判断deliverTime是否已到如果没到就把消息重新塞回同一个延迟 topic如果到了就转发到真正的业务 topic。这中间为了不让延迟 topic 积压太多又不准点需要配合 window 时间轮或者按延迟时间建多个 topic 分组。RocketMQ 内置了延迟消息等级直接用会很舒服但如果你用的是 Kafka这个延迟转发组件就是你的“中间件中间件”。实际开发中我还会在消息头里塞一个expireAt字段消费端做二次校验避免转发器把时间算错。这套方案能解决“30 分钟后消费”的需求但要记住这不是 Kafka 的正常玩法能不用就别自己造轮子实在要用就要把监控和幂等做好。3.5 消息延迟高先从这几个指标查起如果你的场景没要求延迟 30 分钟但 Kafka 消费延迟却越来越高这就不是“能延迟”而是“不该延迟却延迟了”。排查消息延迟高我一般按几步走。第一步看消费组 lag命令是kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group 你的消费组名重点看 LAG 列这个值一直涨说明消费速度跟不上生产速度。第二步看每条消息处理耗时如果单条消息处理里包含数据库查询或远程调用很容易成为瓶颈这时应该加大消费者并发或者把重逻辑拆分到别的地方。第三步看配置参数fetch.max.records如果一次性拉太多消息处理不过来会触发max.poll.interval.ms超时导致消费者被踢出组并触发 rebalancerebalance 后又重复拉取形成恶性循环。第四步看分区数和消费者数量分区数如果远小于并发规模消费者再开多也没用。4. 高频考点面试题和让人眼前一亮的两三道答案4.1 高频 Kafka 面试题先对着清单自查Kafka 的面试题说来说去万变不离其宗。我帮你列一个自查清单每一条都能展开讲 3 分钟才算真正过关Kafka 的工作原理是什么为什么它能支撑高吞吐请讲讲分区、副本、ISR 的作用。生产者 acks 参数有哪几种分别意味着什么Kafka 如何保证消息不丢失消费者如何保证不重复消费如何保证消息消费的顺序性消费者组和 rebalance 是怎么回事如果消费 lag 很高怎么排查和优化Kafka 的 offset 存在哪里Kafka 和 Pulsar、RabbitMQ 有什么区别Kafka 分区数一般设置多少为什么不是越多越好这些问题表面是考知识点实际是考你对 Kafka 的完整链路理解。清单里前面几个会在下面两节重点拆解Pulsar 的对比单独放到 4.4 节聊。4.2 为什么 Kafka 吞吐量大给出一条完整的答题链路面试官问“Kafka 为什么快”最怕听到的回答是“因为它批量发送”“因为它顺序写”这种碎片答案。更好的答题姿势是把整条链路串起来生产者并行写入多个分区每个分区内部顺序追加消息攒成批次批量发送Broker 收到消息后追加到日志文件末尾这个顺序写充分利用磁盘顺序 IO写完后数据留在页缓存里消费者读取时大概率命中页缓存不需要磁盘 IO最终网络发送时通过零拷贝把数据从页缓存直接送到网卡。这样说下来你不仅解释了高吞吐的机制还展示了从 Producer 到 Consumer 的全局视角。顺着这条线面试官如果再追问“为什么分区多了能提升吞吐”你可以回答分区是并行度的单位分区越多Broker 侧可以并行写入的文件更多消费者侧也可以有更多消费者线程并行处理但分区越多也意味着文件句柄、客户端线程、元数据量增大所以不是无限扩张的。4.3 如何保证 Kafka 消息不丢、不重复、不乱序这是面试里的全家桶问题实际上需要区分 “Producer - Broker” 和 “Broker - Consumer” 两段来谈。先说不丢。Producer 端设置acksall表示消息要等所有同步副本写入成功才算成功同时开启重试retries并配上enable.idempotencetrue防止重试造成重复。Broker 端设置min.insync.replicas2这样至少两个副本同步成功才会 ack避免 Leader 单独写成功就返回。Consumer 端要确保处理完成后再手动提交 offset避免进程在未处理完成时提交导致消息没消费。再说重复。Kafka 语义上有“至少一次”和“最多一次”的选择默认配置下很可能出现重复。生产端幂等解决的是重试导致的重复写入但消费端仍可能因 rebalance、手动提交时机产生重复消息。最可靠的办法是消费端做幂等比如利用数据库唯一键、Redis 幂等表保证同一条消息重复执行也不会影响最终结果。精确一次语义在 Kafka Streams 或 Flink 等系统里可以结合事务和 checkpoint 实现但业务消费端最实用的还是自带幂等逻辑。最后说顺序。消息顺序性的前提是“同一个 key 进同一个分区”因为只有分区内部有序跨分区无法保证全局顺序。具体配置是生产消息时指定 key比如订单号所有同一个订单号的消息都会路由到同一分区。还需要注意把max.in.flight.requests.per.connection设为 1或者开启幂等后设为 5防止请求重试导致后续消息先到达。面试时把这三层分开讲逻辑会非常清楚。4.4 Kafka 和 Pulsar 怎么选资料丰富度到底差在哪有人会问“Pulsar 和 Kafka 哪个资料更丰富一些”这个问题问得很实际。我的看法是虽然 Pulsar 在架构上有不少亮点比如存储计算分离、多租户、地域复制、内置延迟队列但落到中文资料和实战案例Kafka 的丰富程度确实高一个档次。原因不难理解。Kafka 已经在各大公司大规模落地十几年生态组件、踩坑文章、面试题、运维工具都非常成熟。你遇到一个问题搜一下基本能找到前人答案Pulsar 社区虽然也在快速进步但遇到冷门状态可能要去 GitHub issue 里翻半天中文资料更少。选型如果不考虑商业支持团队又缺乏深度调优能力Kafka 往往是更稳妥的起点。但这不意味着 Pulsar 不好如果你的需求是多租户极强隔离、存储与计算分开扩容Pulsar 的确值得认真评估。资料丰富度是参考但不是唯一决定性指标。5. 实战排查从 Docker 报错到 SpringBoot、Canal、Flink5.1 Docker 里 Error while fetching metadata with correlation id90% 是监听器配置问题这是 Kafka 新手最常见的报错没有之一。报错原文一般是ERROR while fetching metadata with correlation id ...核心意思是客户端向 Bootstrap Server 请求元数据失败它拿不到集群里的 broker 信息。为什么拿不到绝大多数情况是 advertised.listeners 配置不对。Broker 启动后会告诉客户端“我在哪个地址可以访问”这个宣传地址就是advertised.listeners。在 Docker 环境里如果不显式配置Broker 可能广播容器内部 ID 或容器名客户端在宿主机上根本无法访问这个地址自然就拉不到元数据。解决思路有两种。一种是像 2.3 节一样把advertised.listeners配成宿主机可达的地址另一种是本地临时试验时把bootstrap.servers也写成127.0.0.1:9092但核心仍然是让 broker 对外宣传一个客户端能访问到的地址。排查时还可以直接在宿主机执行kafka-broker-api-versions.sh --bootstrap-server 127.0.0.1:9092如果报错说明 broker 外部访问链路不通接下来就去检查监听器配置和防火墙。记住这个问题不是网络安全问题也不是 Kafka 死掉了只是“宣传地址”和“实际访问地址”没对齐。5.2 SpringBoot 集成 Kafka 配置详解从消费者到手 ack 一应俱全SpringBoot 集成 Kafka 是很多人真正上手的入口。首先在 pom.xml 里引入spring-kafka依赖。然后配置 application.ymlspring: kafka: bootstrap-servers: 127.0.0.1:9092 producer: key-serializer: org.apache.kafka.common.serialization.StringSerializer value-serializer: org.apache.kafka.common.serialization.StringSerializer acks: all consumer: group-id: my-group enable-auto-commit: false auto-offset-reset: earliest key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.apache.kafka.common.serialization.StringDeserializer listener: ack-mode: manual_immediate生产端直接注入KafkaTemplateService public class KafkaProducerService { private final KafkaTemplateString, String kafkaTemplate; public KafkaProducerService(KafkaTemplateString, String kafkaTemplate) { this.kafkaTemplate kafkaTemplate; } public void send(String topic, String key, String message) { kafkaTemplate.send(topic, key, message); } }消费端用KafkaListener手动 ackService public class KafkaConsumerService { KafkaListener(topics test-topic, groupId my-group, concurrency 3) public void onMessage(ConsumerRecordString, String record, Acknowledgment ack) { try { System.out.println(收到消息: record.value()); // 业务处理 ack.acknowledge(); } catch (Exception e) { // 记录失败决定是否重试或入死信 } } }这套配置里最需要注意的是ack-mode和concurrency。concurrency表示消费者线程数它不能大于所订阅 topic 的总分区数否则多出的线程只会空转。手动 ack 一定要等业务处理成功再调用否则“假装消费”会导致业务上消息丢失。SpringBoot 版本和 spring-kafka 版本之间的兼容性也值得留意。如果你遇到反序列化失败先看 value 的序列化类型是否匹配再看消息是否被其他序列化器写入过。这类问题在排查时经常被忽略浪费时间。5.3 Canal 集成 KafkaMySQL 变更数据到 SpringBoot 消费Canal 是监听 MySQL binlog 的中间件配合 Kafka 可以把数据库变更实时同步到其他系统比如更新缓存、同步 ES、驱动事件流。从部署到消费可以拆成三步。第一步在 MySQL 开启 binlog并把 binlog_format 设为 ROW。Canal 本质是模拟 MySQL 从库所以需要主库授权一个专用账号。第二步下载 Canal修改canal.properties把消息输出方式从 TCP 改成 Kafkacanal.serverMode kafka kafka.bootstrap.servers 127.0.0.1:9092 canal.mq.topic canal-test接着在 instance 配置里指定要监听哪些库哪些表启动后 Canal 会把 binlog 变更转成消息发到 Kafka。第三步业务系统只要写一个普通的KafkaListener监听canal-testtopic就能拿到结构化的变更事件。Canal 消息里字段比较多格式类似{data: [...], old: [...], type: INSERT/UPDATE/DELETE, database: ..., table: ...}消费时需要按需解析。实际生产里还要注意幂等和顺序。Canal 默认保证同一行记录的操作有序但如果你并发消费同一个表的多个分区就可能打乱顺序。如果下游强依赖行级变更顺序就按表主键或行 ID 作为 Kafka key保证同一行消息进同一分区。5.4 Flink 消费 Kafka 写入 Elasticsearch一条实时数仓的典型链路Kafka 最常见的搭档还有一个就是 Flink典型链路是 Kafka 作为流式消息总线Flink 做实时计算再把结果写入 Elasticsearch。这套架构在日志分析、用户画像、实时指标等场景里很常见。用 Flink SQL 写是最省事的。先定义 Kafka 源表CREATE TABLE kafka_source ( id STRING, name STRING, ts TIMESTAMP(3), WATERMARK FOR ts AS ts - INTERVAL 5 SECOND ) WITH ( connector kafka, topic input-topic, properties.bootstrap.servers 127.0.0.1:9092, properties.group.id flink-group, scan.startup.mode latest-offset, format json );再定义 Elasticsearch 结果表CREATE TABLE es_sink ( id STRING, name STRING, ts TIMESTAMP(3), PRIMARY KEY (id) NOT ENFORCED ) WITH ( connector elasticsearch-7, hosts http://127.0.0.1:9200, index user_index, format json );最后一句 INSERT INTO 就能跑起来。Flink 的强大之处在于它天然支持 checkpoint能把 Kafka 的 offset 消费进度和 ES 写入做成端到端的状态一致性实现不丢不重。这套链路对排查问题也有帮助如果 ES 写入变慢先去 Lag 看是 Kafka 消费被卡住还是 Flink 算子处理慢还是下游 ES 瓶颈分层隔离会非常有条理。6. 最后聊聊我自己的几点体会Kafka 用久了才有感觉最后分享几个我在实战里被教训出来的经验。第一任何“连不上”的问题第一反应不要去查集群是不是挂了先去看 advertised.listeners 和客户端 bootstrap.servers 是不是对得上这一条至少能帮你省掉半天时间。第二分区数不要拍脑袋定它要和业务流量、消费者并发、Broker 磁盘性能一起评估后期改分区数虽然 Kafka 支持但会引起数据重分布代价不小。第三面试讲 Kafka 一定要讲因果链。快不光是顺序写它是批量、分区、页缓存、零拷贝等一串机制叠加的结果可靠也不光是一个参数它是生产端、Broker、消费端三层配合的结果。把链路讲顺比背一百个面试题管用。第四不要什么都指望 Kafka。延迟队列、定时消息、复杂路由这些场景Kafka 能做但非常费劲适合的中间件各有各的优势。技术选型从来不是“谁最强选谁”而是“谁最适合当前场景选谁”。把这些原则记住你再回头看 Kafka就会发现它没那么玄但也远不是一两句话能讲透的。
Kafka核心原理与实战：从高吞吐到消息可靠性全解析
Kafka 这几年几乎成了后端简历上的标配出去面试十家有八家都会问。但真要把它讲清楚很多人又容易卡在“能用但说不透”的阶段环境能搭起来生产消费能跑通可一旦被问底层原理、消息可靠性、延迟怎么降就支支吾吾了。这篇就当是一份 Kafka 教程性质的总结把核心原理、部署落地、高频考点和实际排查串在一起尽量用大白话讲逻辑而不是堆概念。看的时候不用急着背先跟着链路走一遍你会发现 Kafaka 的设计其实是一条很顺的因果链。1. 先把 Kafka 是什么讲透从工作模型到选型场景1.1 Kafka 的核心角色和消息流转模型Kafka 的本质是一个分布式提交日志distributed commit log这个定位非常关键。传统消息队列强调“队列”消息被消费后往往就没了Kafka 更强调“日志”消息按顺序追加到分区里消费者通过 offset 记录自己读到哪读完之后消息还留在磁盘上直到超过保留时间才会被清理。Kafka 里最基本的几个角色Producer 负责把消息发到 TopicTopic 被拆成多个 Partition每个 Partition 内部是严格有序的Consumer 以消费者组Consumer Group为单位订阅 Topic一个分区只会被同一个组内的一个消费者消费保证同一分区消息处理不打架。Broker 就是承载这些 Topic 分区的服务节点一个 Kafka 集群通常由多个 Broker 组成。我比较喜欢把 Topic 想象成一个巨大的书架Partition 是这本大书里的分册消息是分册里按页号连续写的文字Consumer Group 里的每个消费者各领几本分册去读。Page 号就是这个故事里的 offset。这样的抽象能帮你后面理解很多设计为什么 Kafka 吞吐高、为什么能回放、为什么消费组增减节点会触发 rebalance。1.2 Kafka 的定位它和普通消息队列到底差在哪很多人第一反应是“Kafka 不就是个消息队列”这句话不能说错但会低估它的能力。Kafka 官方给自己的定义是“分布式事件流平台”消息队列只是它众多能力里的一部分。和 RabbitMQ、ActiveMQ 这类传统 MQ 相比最明显的差异是消息留存模型。传统 MQ 更适合点对点的任务分发消息被一个消费者拿走处理完基本就该从内存或队列里删掉。Kafka 的消息保存在磁盘上消费者只是在游标往前走所以天然支持多个消费者组各自独立消费同一份数据谁也不会影响谁。这个特性让 Kafka 在日志采集、指标监控、用户行为追踪、数据管道等场景里特别吃香。比如你有一堆埋点日志既要进实时计算又要进数仓做离线分析还可能要同步到 Elasticsearch 做检索一份数据多个组分别消费就行完全不用复制多份。正是这种“一份数据多方使用”的模型让它成为实时数仓和数据湖选型里绕不开的角色。1.3 什么时候别用 Kafka避坑聊选型的时候不能只说 Kafka 的好否则就是误导。如果你每天的流量很小比如几千条订单消息业务又要复杂路由、死信队列、按消息维度延迟重试那 Kafka 不一定是最优解。这个体量下 RabbitMQ 或者一些云厂商的 MQ 服务可能更省心配置简单能直接满足需求。Kafka 的擅长区间是“高吞吐、多订阅、顺序追加、后续回放”代价是组件多、参数多、运维门槛高。为了每天几千条消息去维护一套 Kafka 集群跟用大炮打蚊子差不多。还有一类场景比如 RPC 调用之间需要毫秒级的低延迟和强可靠也不建议硬上 Kafka它追求的是吞吐优先单条消息延迟虽然不高但整体架构和参数调优并不轻松。一句话技术选型先看场景是否匹配再看团队能不能接住运维负担最后才轮到性能对比。2. 环境准备Kafka 下载、安装、集群、可视化工具一条龙2.1 下载与单机安装先把配置里最关键的两个地方盯住网上关于 Kafka 下载安装的教程非常多但很多人照做还是起不来问题往往不是命令不对而是对配置理解不够。先去 Apache Kafka 官网或国内镜像下载二进制压缩包版本建议选 3.5 以上毕竟新的 KRaft 模式越来越成熟。下载后解压如果只跑单机核心是修改 config/server.properties。Kafka 3.x 以后支持两个模式传统 ZooKeeper 模式和 KRaft 模式。KRaft 模式不需要额外起 ZooKeeper节点自己就是 Controller Candidate部署和维护都简单不少。新项目我比较推荐直接用 KRaft。单机示范配置可以参考process.rolesbroker,controller node.id1 controller.quorum.voters1localhost:9093 listenersPLAINTEXT://:9092,CONTROLLER://:9093 inter.broker.listener.namePLAINTEXT advertised.listenersPLAINTEXT://localhost:9092 controller.listener.namesCONTROLLER log.dirs/tmp/kraft-combined-logs第一遍跑 Kafka 的人最容易栽在两个地方。一个是 Java 版本太低Kafka 3.x 要求 JDK 8 以上推荐 11 或 17另一个是 advertised.listeners 配置不对后续客户端连接会出现各种连不上。配置完成后先执行分区格式化命令KRaft 模式需要先格式化存储目录再启动服务顺序搞错也会启动失败。启动成功后再用 kafka-topics.sh 创建第一个 topic用 kafka-console-producer.sh 和 kafka-console-consumer.sh 验证收发环境就算通了。2.2 Kafka 集群安装三个节点这样配置才能保证高可用生产环境基本不会单节点裸奔Kafka 的高可用依赖副本机制只有多 Broker 才能形成副本。集群节点数量一般至少 3 个才能容忍挂掉一个节点并保证多数副本仍然存活。如果继续用 KRaft 模式每个节点配置文件类似但 node.id 不能重复controller.quorum.voters 要写全三个节点的地址和端口。比如三台机器 192.168.1.11、192.168.1.12、192.168.1.13每个节点配置里都要写process.rolesbroker,controller node.id1 controller.quorum.voters1192.168.1.11:9093,2192.168.1.12:9093,3192.168.1.13:9093 listenersPLAINTEXT://192.168.1.11:9092,CONTROLLER://192.168.1.11:9093 advertised.listenersPLAINTEXT://192.168.1.11:9092 log.dirs/data/kraft-combined-logs需要注意advertised.listeners 要写客户端真正能访问到的地址。如果 Broker 之间走内网 IP客户端也在内网就写内网 IP如果有域名或公网映射就写对应的外部地址。很多“集群起来了但客户端连不上”的情况基本都是这里不一致导致的。集群启动后建议创建 topic 时把副本因子设成 2 或 3比如--replication-factor 3 --partitions 3。同时把min.insync.replicas配置为 2配合生产端 acksall 使用能避免 Leader 挂掉时丢消息。想知道集群里有哪些节点在服务用kafka-metadata.sh shell或查看 metrics 都能判断。2.3 用 Docker Compose 快速起一套 Kafka很多本地开发和测试场景不想在本机装一堆依赖直接上 Docker 是最快的。但 Docker 里的 Kafka 比裸机多一层网络映射配置问题被放大所以这里单独列一节。下面是一份可用的 docker-compose.yml用的是 bitnami 镜像内置了 KRaft省掉 ZooKeeperservices: kafka: image: bitnami/kafka:3.6 container_name: kafka ports: - 9092:9092 environment: - KAFKA_CFG_NODE_ID0 - KAFKA_CFG_PROCESS_ROLEScontroller,broker - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS0kafka:9093 - KAFKA_CFG_LISTENERSPLAINTEXT://:9092,CONTROLLER://:9093 - KAFKA_CFG_ADVERTISED_LISTENERSPLAINTEXT://127.0.0.1:9092 - KAFKA_CFG_CONTROLLER_LISTENER_NAMESCONTROLLER - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAPCONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT - ALLOW_PLAINTEXT_LISTENERyes volumes: - kafka_data:/bitnami/kafka volumes: kafka_data:这组配置最关键的是KAFKA_CFG_ADVERTISED_LISTENERSPLAINTEXT://127.0.0.1:9092。因为容器内部监听的地址是:9092而宿主机端口 9092 映射到了容器的 9092所以对外宣传的地址必须用127.0.0.1:9092否则你在宿主机上的客户端访问时会拿到一个容器内部的域名或者 IP然后报Error while fetching metadata with correlation id。这个错后面 5.1 节专门讲。Docker 方式很适合本地快速验证但要记住容器重启后数据是否保留取决于 volume 是否挂载。临时测试可以不挂开发环境建议挂上持久化目录别等集群崩了才后悔。2.4 Kafka 可视化工具别再只用命令行敲了命令行在排查问题时很有用但日常看消息、看消费 lag、手动调试 topic有个图形界面会舒服很多。现在常用的 Kafka 可视化工具我整理成一张对比表格工具名称定位优点适合场景Offset Explorer原 Kafka Tool桌面客户端稳定功能全查看分区、offset、消息体很方便个人日常查看Kafka-UIprovectusWeb 工具开源支持多集群、Schema Registry、动态查看 topic团队共享、测试环境KafdropWeb 工具轻量Docker 起非常快界面简洁快速预览消息Conduktor客户端/企业体验好功能丰富但收费商业团队我的习惯是本地单个集群用 Offset Explorer 最省事团队协作看测试环境我直接部署 Kafka-UI浏览器打开就能看。注意图形工具连接 Kafka 时填的 bootstrap servers 也必须和 advertised.listeners 对上否则一样连不上。工具只是辅助重点是你脑子里对 topic、分区、offset 的模型足够清晰。3. 核心原理消息从生产到消费中间发生了什么3.1 Producer 端分区策略和批量发送为什么能提高吞吐一条消息从 Producer 发出到 Broker 落盘中间并不是“发送一条写入一条”的简单流程。Kafka 的 Producer 内部有一个消息累加器RecordAccumulator它先把很多消息攒成批次batch再由后台发送线程批量发出去。这就是 Kafka 高效的重要起点。Producer 会先经过序列化器把消息转成字节然后由分区器决定这条消息进哪个分区。分区逻辑默认是这样如果消息指定了 partition就直接用没指定但 key 不为空就对 key 做哈希取模key 也为空就用粘性分区策略尽量让一批消息集中写到一个分区减小网络开销和分区切换开销。关于批量发送有个简单的估算可以帮你理解为什么参数重要。假设每条消息 1KBbatch.size 设置为 16KB那么一个 batch 理论上能装 16 条消息。如果 linger.ms 设置为 5ms就是说最多等 5ms消息不足 batch 大小也会发送。这个设计本质是用很小的延迟换吞吐非常适合日志、埋点、指标这类允许轻微延迟的场景。如果你的业务对延迟极度敏感又想拿到高吞吐就需要结合机器规格和压测结果去调。3.2 Broker 端顺序写、页缓存和零拷贝Kafka 性能的三大支柱Kafka 之所以敢说自己能撑百万级吞吐核心在 Broker 的存储设计。很多人一听“消息落到磁盘”就觉得慢但 Kafka 做的是顺序追加写消息永远写到分区日志文件的末尾。机械硬盘随机写和顺序写的性能差距可能有一个数量级以上SSD 虽然随机写也不错但顺序写依然更稳定。另一个重要机制是页缓存。Kafka 写入时先落到操作系统页缓存由操作系统在合适时机刷到磁盘读的时候如果数据还热在页缓存里根本不用碰磁盘。这不光是省了一次 IO还绕开了 JVM 堆内存的很多烦恼所以 Kafka 默认并不建议盲目调大堆内存反而更依赖操作系统缓存。零拷贝则是读取路径的杀器。传统读文件然后发网络需要经过内核到用户态、用户态再回到内核的多次拷贝Kafka 可以用 sendfile 系统调用直接在内核态把页缓存数据发送到网卡省掉两次拷贝。面试聊到“Kafka 为什么快”把这三点串成一条因果链讲比背几个名词强得多。3.3 Consumer 端消费者组、Rebalance 和位移提交消费端的核心是消费者组和 offset 的管理。一个消费者组订阅一个 TopicTopic 的每个分区只被组内一个消费者持有这样保证分区内数据不会被同一个组重复消费。如果消费者个数大于分区数那多出来的消费者会空转这就是为什么消费能力不够时要优先看分区数。当消费者组里的成员增多或减少或者订阅的 topic 分区数变化时会触发 rebalance也就是重新分配分区。rebalance 期间消费者会暂停消费整个过程如果频繁发生就是消费者重复消费和消费延迟的常见元凶。新版 Kafka 支持 cooperative rebalance能尽量做到先分配后撤销减少阻塞时间但依然不建议用数量频繁波动的消费者。offset 是消费者消费位置的指针Kafka 老版本存在 ZooKeeper 里新版本默认提交到__consumer_offsets这个内部 topic。消费端有两个典型姿势自动提交和手动提交。自动提交省事但可能重复消费或丢消息手动提交灵活能控制确认时机。生产环境我通常建议enable.auto.commitfalse处理完消息再手动提交保证业务和 offset 相对同步。3.4 如何实现延迟 30 分钟消费Kafka 没有内置延迟队列怎么办“Kafka 如何延迟 30 分钟消费”是很多搜索里出现的高频词。先说结论Kafka 原生没有延迟队列能力它只保证按 offset 顺序投递不会因为你指定一个延迟时间就让消息 30 分钟后再出现。所以项目里碰到这种需求就要自己搭一层。最常见的方案是“延迟 topic 定时转发”。具体做法是生产者把带目标投递时间的消息发到一个内部延迟 topic这个 topic 只给一个调度服务消费调度服务每隔一定时间扫描消息判断deliverTime是否已到如果没到就把消息重新塞回同一个延迟 topic如果到了就转发到真正的业务 topic。这中间为了不让延迟 topic 积压太多又不准点需要配合 window 时间轮或者按延迟时间建多个 topic 分组。RocketMQ 内置了延迟消息等级直接用会很舒服但如果你用的是 Kafka这个延迟转发组件就是你的“中间件中间件”。实际开发中我还会在消息头里塞一个expireAt字段消费端做二次校验避免转发器把时间算错。这套方案能解决“30 分钟后消费”的需求但要记住这不是 Kafka 的正常玩法能不用就别自己造轮子实在要用就要把监控和幂等做好。3.5 消息延迟高先从这几个指标查起如果你的场景没要求延迟 30 分钟但 Kafka 消费延迟却越来越高这就不是“能延迟”而是“不该延迟却延迟了”。排查消息延迟高我一般按几步走。第一步看消费组 lag命令是kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group 你的消费组名重点看 LAG 列这个值一直涨说明消费速度跟不上生产速度。第二步看每条消息处理耗时如果单条消息处理里包含数据库查询或远程调用很容易成为瓶颈这时应该加大消费者并发或者把重逻辑拆分到别的地方。第三步看配置参数fetch.max.records如果一次性拉太多消息处理不过来会触发max.poll.interval.ms超时导致消费者被踢出组并触发 rebalancerebalance 后又重复拉取形成恶性循环。第四步看分区数和消费者数量分区数如果远小于并发规模消费者再开多也没用。4. 高频考点面试题和让人眼前一亮的两三道答案4.1 高频 Kafka 面试题先对着清单自查Kafka 的面试题说来说去万变不离其宗。我帮你列一个自查清单每一条都能展开讲 3 分钟才算真正过关Kafka 的工作原理是什么为什么它能支撑高吞吐请讲讲分区、副本、ISR 的作用。生产者 acks 参数有哪几种分别意味着什么Kafka 如何保证消息不丢失消费者如何保证不重复消费如何保证消息消费的顺序性消费者组和 rebalance 是怎么回事如果消费 lag 很高怎么排查和优化Kafka 的 offset 存在哪里Kafka 和 Pulsar、RabbitMQ 有什么区别Kafka 分区数一般设置多少为什么不是越多越好这些问题表面是考知识点实际是考你对 Kafka 的完整链路理解。清单里前面几个会在下面两节重点拆解Pulsar 的对比单独放到 4.4 节聊。4.2 为什么 Kafka 吞吐量大给出一条完整的答题链路面试官问“Kafka 为什么快”最怕听到的回答是“因为它批量发送”“因为它顺序写”这种碎片答案。更好的答题姿势是把整条链路串起来生产者并行写入多个分区每个分区内部顺序追加消息攒成批次批量发送Broker 收到消息后追加到日志文件末尾这个顺序写充分利用磁盘顺序 IO写完后数据留在页缓存里消费者读取时大概率命中页缓存不需要磁盘 IO最终网络发送时通过零拷贝把数据从页缓存直接送到网卡。这样说下来你不仅解释了高吞吐的机制还展示了从 Producer 到 Consumer 的全局视角。顺着这条线面试官如果再追问“为什么分区多了能提升吞吐”你可以回答分区是并行度的单位分区越多Broker 侧可以并行写入的文件更多消费者侧也可以有更多消费者线程并行处理但分区越多也意味着文件句柄、客户端线程、元数据量增大所以不是无限扩张的。4.3 如何保证 Kafka 消息不丢、不重复、不乱序这是面试里的全家桶问题实际上需要区分 “Producer - Broker” 和 “Broker - Consumer” 两段来谈。先说不丢。Producer 端设置acksall表示消息要等所有同步副本写入成功才算成功同时开启重试retries并配上enable.idempotencetrue防止重试造成重复。Broker 端设置min.insync.replicas2这样至少两个副本同步成功才会 ack避免 Leader 单独写成功就返回。Consumer 端要确保处理完成后再手动提交 offset避免进程在未处理完成时提交导致消息没消费。再说重复。Kafka 语义上有“至少一次”和“最多一次”的选择默认配置下很可能出现重复。生产端幂等解决的是重试导致的重复写入但消费端仍可能因 rebalance、手动提交时机产生重复消息。最可靠的办法是消费端做幂等比如利用数据库唯一键、Redis 幂等表保证同一条消息重复执行也不会影响最终结果。精确一次语义在 Kafka Streams 或 Flink 等系统里可以结合事务和 checkpoint 实现但业务消费端最实用的还是自带幂等逻辑。最后说顺序。消息顺序性的前提是“同一个 key 进同一个分区”因为只有分区内部有序跨分区无法保证全局顺序。具体配置是生产消息时指定 key比如订单号所有同一个订单号的消息都会路由到同一分区。还需要注意把max.in.flight.requests.per.connection设为 1或者开启幂等后设为 5防止请求重试导致后续消息先到达。面试时把这三层分开讲逻辑会非常清楚。4.4 Kafka 和 Pulsar 怎么选资料丰富度到底差在哪有人会问“Pulsar 和 Kafka 哪个资料更丰富一些”这个问题问得很实际。我的看法是虽然 Pulsar 在架构上有不少亮点比如存储计算分离、多租户、地域复制、内置延迟队列但落到中文资料和实战案例Kafka 的丰富程度确实高一个档次。原因不难理解。Kafka 已经在各大公司大规模落地十几年生态组件、踩坑文章、面试题、运维工具都非常成熟。你遇到一个问题搜一下基本能找到前人答案Pulsar 社区虽然也在快速进步但遇到冷门状态可能要去 GitHub issue 里翻半天中文资料更少。选型如果不考虑商业支持团队又缺乏深度调优能力Kafka 往往是更稳妥的起点。但这不意味着 Pulsar 不好如果你的需求是多租户极强隔离、存储与计算分开扩容Pulsar 的确值得认真评估。资料丰富度是参考但不是唯一决定性指标。5. 实战排查从 Docker 报错到 SpringBoot、Canal、Flink5.1 Docker 里 Error while fetching metadata with correlation id90% 是监听器配置问题这是 Kafka 新手最常见的报错没有之一。报错原文一般是ERROR while fetching metadata with correlation id ...核心意思是客户端向 Bootstrap Server 请求元数据失败它拿不到集群里的 broker 信息。为什么拿不到绝大多数情况是 advertised.listeners 配置不对。Broker 启动后会告诉客户端“我在哪个地址可以访问”这个宣传地址就是advertised.listeners。在 Docker 环境里如果不显式配置Broker 可能广播容器内部 ID 或容器名客户端在宿主机上根本无法访问这个地址自然就拉不到元数据。解决思路有两种。一种是像 2.3 节一样把advertised.listeners配成宿主机可达的地址另一种是本地临时试验时把bootstrap.servers也写成127.0.0.1:9092但核心仍然是让 broker 对外宣传一个客户端能访问到的地址。排查时还可以直接在宿主机执行kafka-broker-api-versions.sh --bootstrap-server 127.0.0.1:9092如果报错说明 broker 外部访问链路不通接下来就去检查监听器配置和防火墙。记住这个问题不是网络安全问题也不是 Kafka 死掉了只是“宣传地址”和“实际访问地址”没对齐。5.2 SpringBoot 集成 Kafka 配置详解从消费者到手 ack 一应俱全SpringBoot 集成 Kafka 是很多人真正上手的入口。首先在 pom.xml 里引入spring-kafka依赖。然后配置 application.ymlspring: kafka: bootstrap-servers: 127.0.0.1:9092 producer: key-serializer: org.apache.kafka.common.serialization.StringSerializer value-serializer: org.apache.kafka.common.serialization.StringSerializer acks: all consumer: group-id: my-group enable-auto-commit: false auto-offset-reset: earliest key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.apache.kafka.common.serialization.StringDeserializer listener: ack-mode: manual_immediate生产端直接注入KafkaTemplateService public class KafkaProducerService { private final KafkaTemplateString, String kafkaTemplate; public KafkaProducerService(KafkaTemplateString, String kafkaTemplate) { this.kafkaTemplate kafkaTemplate; } public void send(String topic, String key, String message) { kafkaTemplate.send(topic, key, message); } }消费端用KafkaListener手动 ackService public class KafkaConsumerService { KafkaListener(topics test-topic, groupId my-group, concurrency 3) public void onMessage(ConsumerRecordString, String record, Acknowledgment ack) { try { System.out.println(收到消息: record.value()); // 业务处理 ack.acknowledge(); } catch (Exception e) { // 记录失败决定是否重试或入死信 } } }这套配置里最需要注意的是ack-mode和concurrency。concurrency表示消费者线程数它不能大于所订阅 topic 的总分区数否则多出的线程只会空转。手动 ack 一定要等业务处理成功再调用否则“假装消费”会导致业务上消息丢失。SpringBoot 版本和 spring-kafka 版本之间的兼容性也值得留意。如果你遇到反序列化失败先看 value 的序列化类型是否匹配再看消息是否被其他序列化器写入过。这类问题在排查时经常被忽略浪费时间。5.3 Canal 集成 KafkaMySQL 变更数据到 SpringBoot 消费Canal 是监听 MySQL binlog 的中间件配合 Kafka 可以把数据库变更实时同步到其他系统比如更新缓存、同步 ES、驱动事件流。从部署到消费可以拆成三步。第一步在 MySQL 开启 binlog并把 binlog_format 设为 ROW。Canal 本质是模拟 MySQL 从库所以需要主库授权一个专用账号。第二步下载 Canal修改canal.properties把消息输出方式从 TCP 改成 Kafkacanal.serverMode kafka kafka.bootstrap.servers 127.0.0.1:9092 canal.mq.topic canal-test接着在 instance 配置里指定要监听哪些库哪些表启动后 Canal 会把 binlog 变更转成消息发到 Kafka。第三步业务系统只要写一个普通的KafkaListener监听canal-testtopic就能拿到结构化的变更事件。Canal 消息里字段比较多格式类似{data: [...], old: [...], type: INSERT/UPDATE/DELETE, database: ..., table: ...}消费时需要按需解析。实际生产里还要注意幂等和顺序。Canal 默认保证同一行记录的操作有序但如果你并发消费同一个表的多个分区就可能打乱顺序。如果下游强依赖行级变更顺序就按表主键或行 ID 作为 Kafka key保证同一行消息进同一分区。5.4 Flink 消费 Kafka 写入 Elasticsearch一条实时数仓的典型链路Kafka 最常见的搭档还有一个就是 Flink典型链路是 Kafka 作为流式消息总线Flink 做实时计算再把结果写入 Elasticsearch。这套架构在日志分析、用户画像、实时指标等场景里很常见。用 Flink SQL 写是最省事的。先定义 Kafka 源表CREATE TABLE kafka_source ( id STRING, name STRING, ts TIMESTAMP(3), WATERMARK FOR ts AS ts - INTERVAL 5 SECOND ) WITH ( connector kafka, topic input-topic, properties.bootstrap.servers 127.0.0.1:9092, properties.group.id flink-group, scan.startup.mode latest-offset, format json );再定义 Elasticsearch 结果表CREATE TABLE es_sink ( id STRING, name STRING, ts TIMESTAMP(3), PRIMARY KEY (id) NOT ENFORCED ) WITH ( connector elasticsearch-7, hosts http://127.0.0.1:9200, index user_index, format json );最后一句 INSERT INTO 就能跑起来。Flink 的强大之处在于它天然支持 checkpoint能把 Kafka 的 offset 消费进度和 ES 写入做成端到端的状态一致性实现不丢不重。这套链路对排查问题也有帮助如果 ES 写入变慢先去 Lag 看是 Kafka 消费被卡住还是 Flink 算子处理慢还是下游 ES 瓶颈分层隔离会非常有条理。6. 最后聊聊我自己的几点体会Kafka 用久了才有感觉最后分享几个我在实战里被教训出来的经验。第一任何“连不上”的问题第一反应不要去查集群是不是挂了先去看 advertised.listeners 和客户端 bootstrap.servers 是不是对得上这一条至少能帮你省掉半天时间。第二分区数不要拍脑袋定它要和业务流量、消费者并发、Broker 磁盘性能一起评估后期改分区数虽然 Kafka 支持但会引起数据重分布代价不小。第三面试讲 Kafka 一定要讲因果链。快不光是顺序写它是批量、分区、页缓存、零拷贝等一串机制叠加的结果可靠也不光是一个参数它是生产端、Broker、消费端三层配合的结果。把链路讲顺比背一百个面试题管用。第四不要什么都指望 Kafka。延迟队列、定时消息、复杂路由这些场景Kafka 能做但非常费劲适合的中间件各有各的优势。技术选型从来不是“谁最强选谁”而是“谁最适合当前场景选谁”。把这些原则记住你再回头看 Kafka就会发现它没那么玄但也远不是一两句话能讲透的。
