企业官网建设流程全解析

1. 一次把 Kafka 接到 AI 数据链路上的完整记录

Kafka 正式接入 AI，这句话在我这边的落地形态，不是做个 Demo 跑通就完事，而是把 Kafka 真正放到了 AI 应用的数据主链路上，做实时数据供给、事件驱动和异步推理的底座。

先说下背景。我手上有个 AI 应用项目，既要接大模型的流式日志，又要让多个 AI Agent 之间通过事件协作，还要跑本地部署的模型做异步推理。最开始大家想得很简单：AI 应用嘛，HTTP 调接口就行。结果一压测就发现问题，大模型推理动辄几秒到几十秒，同步调用把上游服务全堵住了，日志量一大又把采集链路打爆。后来我拍板把 Kafka 引入作为数据中枢，跑了一段时间，稳定性和扩展性都上来了。

这篇文章不写虚的，全是实际操作。包括 Kafka 集群怎么部署、Docker 安装有哪些坑、可视化工具怎么选、Spring Kafka 和 AI 应用怎么配、生产消费命令到底怎么用、Kafka 能不能重复消费、消息延迟高和 lag 怎么排查、以及 Kafka 和 RabbitMQ 到底怎么选。穿插一些面试常问的点，因为团队最近招人，这些问题我天天都在问别人。

无论你是刚接触 Kafka 的入门者，还是已经在生产环境里被消息队列折磨过的工程师，这篇都值得花十分钟看完。

2. 为什么 AI 应用非要引入 Kafka

2.1 AI 场景下的数据供给痛点

AI 应用和传统后端服务有个本质区别：数据不再是简单的请求-响应，而是持续不断产生的事件流。大模型的每一次调用、Agent 的每一步思考、用户与 AI 的每一轮交互，都是独立事件。

这些事件有几个特点。第一是量大，单个用户和大模型对话一次，中间可能产生几十条中间过程数据；第二是实时性要求高，你希望 AI 应用能尽快感知到新事件并做出响应；第三是数据格式多样，可能是 JSON 日志、模型推理结果、Agent 状态变更，也可能是埋点数据。

如果用传统同步方式处理这些数据，要么全堵在内存队列里，要么靠数据库轮询，要么直接丢消息。这三种方式我都见过在生产环境里翻车。内存队列在进程重启后数据全丢，数据库轮询在高并发下把库拖垮，丢消息就更不用说了，AI 应用丢一条关键事件，可能整个 Agent 的状态就错乱了。

2.2 Kafka 在这条链路里的位置

Kafka 进到 AI 架构里，起的是一个数据中枢的作用。所有 AI 相关的事件，不管是从客户端进来的用户请求事件，还是大模型产生的推理日志事件，还是 AI Agent 之间互相传递的状态事件，统一进 Kafka。下游的 AI 推理服务、日志采集系统、监控告警系统，各自按需消费。

这样做的好处有三个。第一个是解耦，上游生产者不需要关心下游谁在消费，下游消费者也不关心上游数据从哪来；第二个是削峰填谷，AI 场景的流量突发性很强，Kafka 作为缓冲层可以把峰值流量暂时存下来，让下游按自己的节奏消费；第三个是数据可重放，Kafka 的消息默认保存一段时间，你随时可以从某个 offset 重新消费，这在 AI 模型训练数据回放、故障排查、业务审计里太重要了。

相当于给 AI 应用加了一个蓄水池。上游再怎么汹涌澎湃，下游都能稳定地抽水处理。这也是为什么我把 Kafka 定义为 AI 基础设施的核心组件，它不只是消息队列，更是整个 AI 数据流的骨干。

2.3 AI Agent 对事件驱动架构的天然依赖

AI Agent 模式和传统应用最大的区别，在于它不是一个线性流程，而是多个子任务并行协作、互相等待结果的过程。一个 Agent 可能要根据用户指令拆解出多个子任务，子任务之间又有依赖关系。

这种场景用同步调用来编排，复杂度和故障率会指数级上升。但用 Kafka 做事件总线，就顺滑得多。每个 Agent 监听特定主题，收到事件就开始干活，干完活再往下一个主题发送结果事件。A Agent 不需要知道 B Agent 在哪儿、什么时候处理完，只需要把事件发到约定好的主题里就行。

我在项目里就是这样做的。用户提一个需求，API 网关把需求转成事件发送到 task-command 主题，任务编排 Agent 消费后拆解子任务，发送到各子 Agent 对应的主题，子 Agent 处理完把结果发到 task-result 主题，最后由汇总 Agent 整合结果响应给用户。整个链路全是异步的，各个 Agent 之间完全解耦，新增一个 Agent 只需要订阅对应主题就行。

3. Kafka 集群准备与部署实战

3.1 集群规划的一些经验

Kafka 部署方案，我先明确一点：不要单机跑生产。Kafka 单机在 Demo 和本地开发里够用，但生产环境一旦 broker 挂了，整个链路就断了。

集群规模怎么定？我见过很多团队一上来就搞五台、七台机器，其实前期完全没必要。我刚接入的时候用的是三节点集群，每个 broker 分配的角色是：一台作为 controller 节点负责元数据管理，三台都参与数据存储和消费。这个配置应对日均几千万条消息完全没问题。

硬件方面，CPU 核心数建议 8 核以上，内存 16G 起步，这主要给操作系统的 Page Cache 用，因为 Kafka 读写性能高度依赖页缓存。磁盘是重中之重，一定要用 SSD，而且有条件就多块盘做 RAID 或者直接把数据目录分散到多个磁盘。Kafka 是顺序写盘，SSD 和机械硬盘的差距在吞吐量上能拉开一个数量级。

还有一个关键参数是副本因子。Kafka 支持给主题配置多个副本，生产环境我建议至少 2 个副本，这样一台 broker 挂了，数据还能从另一台副本恢复。但副本数也不是越多越好，副本多了写入性能会下降，成本和网络开销都上去了。测试环境下副本数设置成 1 就行，省资源。

3.2 Docker 安装 Kafka 的完整步骤

部署方式我推荐先用 Docker 快速起一套环境。生产环境虽然我后来用了物理机集群，但开发和测试阶段 Docker 是最快的。

需要注意，Kafka 本身不包含 Zookeeper 或 KRaft 模式的选择。老版本 Kafka 依赖 Zookeeper 管理元数据和选举 controller，新版本（2.8 以后）引入了 KRaft 模式，去掉了 Zookeeper 依赖。我用的是 Kafka 3.x 版本，这里整理一下 Docker Compose 方式。

先创建一个 docker-compose.yml 文件：

version: '3' services: kafka: image: bitnami/kafka:3.4 container_name: kafka ports: - "9092:9092" environment: - KAFKA_CFG_NODE_ID=0 - KAFKA_CFG_PROCESS_ROLES=controller,broker - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS=0@kafka:9093 - KAFKA_CFG_LISTENERS=PLAINTEXT://:9092,CONTROLLER://:9093 - KAFKA_CFG_ADVERTISED_LISTENERS=PLAINTEXT://localhost:9092 - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAP=PLAINTEXT:PLAINTEXT,CONTROLLER:PLAINTEXT - KAFKA_CFG_CONTROLLER_LISTENER_NAMES=CONTROLLER - KAFKA_CFG_OFFSETS_TOPIC_REPLICATION_FACTOR=1 - KAFKA_CFG_TRANSACTION_STATE_LOG_REPLICATION_FACTOR=1 - KAFKA_CFG_TRANSACTION_STATE_LOG_MIN_ISR=1 - KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLE=true volumes: - kafka_data:/bitnami/kafka volumes: kafka_data: driver: local

执行 docker-compose up -d 启动。这套配置用的是 KRaft 模式，不需要额外的 Zookeeper 容器，比较清爽。

启动后验证一下是否正常：

docker exec -it kafka kafka-topics.sh --bootstrap-server localhost:9092 --list

能列出主题列表就说明起来了。这里有个坑，我踩过一次：如果宿主机和容器内的网络配置不一致，ADVERTISED_LISTENERS 配成 localhost 会导致容器外部连接不上。本地开发用 localhost 没问题，但要是容器跑在远程服务器上，就得把 localhost 换成服务器 IP 或者域名，不然客户端永远连不上。

还有，bitnami 镜像的配置参数前缀是 KAFKA_CFG_，和官方 apache/kafka 镜像的环境变量命名不太一样，网上很多教程混着抄，照着配容易启动报错。用哪个镜像就查哪个镜像的文档，不要想当然。

3.3 可视化工具选型和使用

Kafka 部署完之后，没有可视化工具是真难受。命令行能查东西，但不直观，尤其是在排查 lag、查看 topic 数据分布的时候，命令行效率很低。

我用过的工具里，比较推荐三个。

第一个是 Kafka UI（原 Kafdrop 的升级版），基于 Web 界面，界面清爽，支持查看 topic 列表、分区信息、消费组状态、浏览消息内容、修改主题配置。Docker 一条命令就能起：

docker run -d --name kafka-ui -p 8080:8080 -e KAFKA_CLUSTERS_0_NAME=local -e KAFKA_CLUSTERS_0_BOOTSTRAPSERVERS=localhost:9092 provectuslabs/kafka-ui:latest

第二个是 Offset Explorer（原 Kafka Tool），桌面客户端，Windows 和 Mac 都有。我一般在开发机上用这个，连接集群后能看到每个消费组的 offset 和 lag，还能直接查看指定分区里的消息内容，排查消息格式问题很方便。

第三个是 Kafka Monitor，偏监控多一点。如果是生产环境需要长期观测集群健康状况，建议接 Prometheus + Grafana 那套，配上 kafka_exporter，lag、吞吐量、磁盘使用率全都有可视化图表。

可视化工具的核心价值，我觉得是让 Kafka 从黑盒变成白盒。之前排查消息延迟，全靠命令行一条一条敲，遇到分布式环境下多个消费组的情况简直要疯。后来用 Kafka UI 一眼就能看到哪个消费组 lag 高，效率提升不是一点半点。

4. Spring Kafka 集成 AI 应用的配置实践

4.1 Spring Kafka 的核心配置项

实际开发里，Java 后端接 Kafka，绝大多数团队用的是 Spring Kafka。接入 AI 应用时，配置上有些坑需要注意，我先给一份经过验证的 yaml：

spring: kafka: bootstrap-servers: kafka-1:9092,kafka-2:9092,kafka-3:9092 producer: key-serializer: org.apache.kafka.common.serialization.StringSerializer value-serializer: org.apache.kafka.common.serialization.StringSerializer acks: all retries: 3 compression-type: lz4 batch-size: 16384 linger-ms: 5 consumer: key-deserializer: org.apache.kafka.common.serialization.StringDeserializer value-deserializer: org.apache.kafka.common.serialization.StringDeserializer group-id: ai-application-group enable-auto-commit: false auto-offset-reset: earliest max-poll-records: 500 fetch-min-size: 1024 listener: type: batch concurrency: 6 ack-mode: manual

这里说几个关键配置的选择逻辑。

bootstrap-servers 配三个 broker 地址是为了高可用，一个挂了客户端会自动切换到其他 broker。

producer 端的 acks 设成 all，意思是消息要等所有同步副本都写入成功才返回确认。这会影响一些性能，但保证了消息不丢。对于 AI 场景，一条用户指令丢了可能导致整个 Agent 链路状态错乱，这个代价我承受不起。

compression-type 用的 lz4，压缩率虽然不是最高，但 CPU 开销小，适合高吞吐场景。AI 场景的消息体通常比较大，模型输出的 JSON 有时候几十 KB，不压缩网卡直接成为瓶颈。

consumer 端有一个关键设置：enable-auto-commit: false，把自动提交关掉。很多人图省事用自动提交，结果一开就出问题。自动提交是定时批量提交 offset 的，如果在本次提交前消费者处理消息失败了，重试时已经提交的 offset 会让部分消息被跳过。而且 commit 有可能会发生在处理完成之前，导致重启后丢消息。

listener 这块，我把 ack-mode 设成 manual，配合 enable-auto-commit: false，手动确认消息，确保处理成功之后才提交 offset。type 设成 batch，批量消费，batch 模式下消费效率更高。concurrency 设成 6，意思是开启 6 个并发消费线程，对应 Kafka 分区数要大于等于 6，否则部分并发会闲置。

4.2 生产消费命令速查

开发过程中，命令行的生产消费命令是必须熟练的。我整理几个高频命令。

先创建主题。用 Docker 部署的话，进容器执行：

docker exec -it kafka kafka-topics.sh --bootstrap-server localhost:9092 --create --topic ai-request-topic --partitions 6 --replication-factor 1

分区数设 6，是为了和 Spring 消费者 concurrency=6 匹配。

查看主题列表：

docker exec -it kafka kafka-topics.sh --bootstrap-server localhost:9092 --list

查看指定主题的详情，包括分区数、副本分配：

docker exec -it kafka kafka-topics.sh --bootstrap-server localhost:9092 --describe --topic ai-request-topic

生产一条测试消息：

docker exec -it kafka kafka-console-producer.sh --bootstrap-server localhost:9092 --topic ai-request-topic

然后输入消息内容，回车发送。Ctrl+C 退出。

消费消息：

docker exec -it kafka kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic ai-request-topic --from-beginning

这里有一个新手常问的问题：kafka 生产消费命令启动一次会一直运行吗？答案是 Kafka 的生产者和消费者都是持续运行的进程。生产者启动后一直等待输入，不会自动退出；消费者启动后会持续监听并消费新消息，也不会自动退出。这和 RabbitMQ 的设计类似，都是守护式进程。

4.3 Kafka 能重复消费吗？幂等怎么设计

这个问题是我面试必问的。答案是：能，而且 Kafka 的重复消费是常态，不是异常。

重复消费发生的原因主要有三种。第一种是消费者在处理消息后、提交 offset 之前宕机了，重启后 Kafka 认为该消息未被消费，会重新投递；第二种是手动提交 offset 时，提交失败重试，导致已经处理过的消息再次被拉到；第三种是消费端业务代码抛出异常，消息被投入死信队列或者重试主题，再次被消费。

既然重复消费无法避免，那业务端就必须做好幂等设计。AI 场景里幂等特别重要，因为一条用户请求被重复处理，可能产生两个重复的推理任务，浪费 GPU 资源不说，还可能给用户重复扣费。

幂等的常用方案有三种。第一种是基于唯一业务 ID 去重，生产者发送消息时带上一个全局唯一的 requestId，消费者在处理前先查一下这个 requestId 是否处理过，处理过就跳过。实现上可以用 Redis SETNX 做去重，或者查数据库唯一索引。第二种是利用数据库的唯一约束，直接把 requestId 作为业务表的主键或者唯一索引，重复插入直接报错或者 ignore。第三种是状态机校验，只允许从某个状态流转到另一个状态，重复事件到的时候发现状态已经变了，直接丢弃。

我在项目里用的是第一种加第二种组合。API 网关生成 requestId，消费者处理前用 Redis 的 setnx 做一次短时间窗口的幂等拦截，同时业务表里 requestId 也建了唯一索引兜底。双保险之下，重复消费基本能做到业务无感知。

5. 三大典型 AI 接入场景实战

5.1 场景一：AI 大模型流式日志采集

大模型的推理过程和我们普通接口调用不一样，不是一次返回结果，而是一个 token 一个 token 地往外冒。这个过程产生的日志量非常大，而且需要实时采集和分析。

我业务里的具体做法是：大模型服务端把每次推理的 token 输出日志、prompt 内容、响应延迟、session 信息等，全部发送到一个叫 model-inference-log 的主题。下游接了日志采集程序，消费这些日志后做结构化处理，一部分进 Elasticsearch 供检索，一部分进数据仓库做分析。

还有一个体验优化是流式响应的中间态数据。前端在等大模型回复的时候，需要展示打字机效果，这个中间过程数据如果用 HTTP 长连接做，后端很难管理连接状态。后来我把中间态结果也发到 Kafka，前端通过 WebSocket 做一个适配层，从 Kafka 里把增量数据推给前端。效果就是用户看到 AI 逐字输出的同时，后端不需要维护大量长连接，资源占用大幅下降。

从操作层面，这个场景里要注意的是主题分区的 key 设计。我用 sessionId 作为消息 key，这样同一个会话的消息一定落到同一个分区里，保证了同一用户推理事件的顺序性。顺序很重要，大模型的输出乱序了，那前端展示的内容就是错乱的。

5.2 场景二：AI Agent 事件总线

AI Agent 场景前面已经简单提到了。我再细化一下，因为这是我这次接触 AI 后觉得最值得写的东西。

Agent 之间的事件传递，我用 Kafka 做了五个主题：

• agent-task-command：任务下发主题，编排 Agent 把拆解好的子任务发到这里
• agent-task-result：结果汇总主题，各个子 Agent 完成工作后把结果发到这里
• agent-status-change：状态变更主题，所有 Agent 的心跳和状态变化都发到这个主题
• agent-message-bus：通用消息总线，Agent 之间非结构化的临时消息交流
• agent-error-report：错误上报主题，Agent 出错后的异常信息汇总

举一个真实场景。用户让 AI 帮忙写一份市场分析报告。编排 Agent 收到指令后，把任务拆解成“收集市场数据”“分析竞品动态”“生成报告初稿”三个子任务，分别发布到 agent-task-command 主题，消息体里有子任务 ID 和对应的 Agent 类型。数据收集 Agent 消费到任务后，去各个数据源拉数据，处理完发送结果到 agent-task-result 主题。编排 Agent 监听这个主题，发现数据收集完成之后，再触发下一个阶段的子任务。

这个设计带来的最大收益是扩展性。我后来新增了一个“竞品监控 Agent”，只需要写一个消费者订阅 agent-task-command 主题，解析任务类型，如果是自己负责的类型就处理，完事再发结果到 agent-task-result，整个主链路代码一行没改。

5.3 场景三：本地部署 AI 模型异步推理

本地部署 AI 模型是现在很火的方向，很多企业因为数据隐私和成本原因，把模型部署在自己机房。但本地模型的吞吐量通常有限，一个模型实例同时只能处理有限的请求。

直接同步调用本地模型，一旦并发上来，模型服务直接被打崩。所以我把推理请求设计成了异步模式。用户请求先发送到 ai-inference-request 主题，推理服务从主题里拉取请求，逐个交给模型推理，推理完成后把结果发送到 ai-inference-response 主题，请求方再通过消息订阅拿到结果。

这套方案落地后，系统支持的并发能力取决于 Kafka 的吞吐量，而不是模型的并发能力。请求全部在 Kafka 里排队，模型以最大稳定速率消费处理。用户体验上从原来的“接口超时”变成“处理中，请稍后”，这个体验本质上完全不同。

这里有个细节，推理服务的消费能力要实时监控。如果消费 lag 持续增长，说明模型处理不过来，需要扩容推理实例或者降级。我接了一个简单的监控脚本，每 5 分钟查询一次 ai-inference-request 主题的消费组 lag，超过阈值就触发告警。

6. 性能排查：消息延迟高与 lag 的处理实录

6.1 查看 topic 中的数据

排查性能问题，第一步是先看清楚 topic 里的数据状态。

查看某个 topic 从指定 offset 开始消费指定数量的消息：

docker exec -it kafka kafka-console-consumer.sh --bootstrap-server localhost:9092 --topic ai-request-topic --partition 0 --offset 100 --max-messages 10

查看消费组当前的消费进度：

docker exec -it kafka kafka-consumer-groups.sh --bootstrap-server localhost:9092 --describe --group ai-application-group

执行后输出类似这样：

GROUP TOPIC PARTITION CURRENT-OFFSET LOG-END-OFFSET LAG ai-application-group ai-request-topic 0 12345 12456 111 ai-application-group ai-request-topic 1 23456 23478 22

CURRENT-OFFSET 是消费组当前消费到的位置，LOG-END-OFFSET 是主题生产到的最新位置，两者的差值 LAG 就是积压量。LAG 持续增长，说明消费速度跟不上生产速度，这是阿里云上最常见的 Kafka 性能问题之一。

6.2 消息延迟高，到底卡在哪一环

Kafka 消息延迟高，很多人第一反应是网络问题，但实际排查下来，瓶颈往往在几个容易被忽视的地方。

第一个是消费者处理逻辑耗时太长。AI 场景里特别常见，消费者拿到消息后要调用大模型接口，如果大模型响应 30 秒，那消费者线程就阻塞 30 秒，lag 自然飙升。这时候最简单的优化是调整消费并发数和加大分区数，让更多线程并行处理。我之前做过一次压测，把 concurrency 从 3 调到 8，lag 直接下降了一半多。

第二个是 fetch.min.bytes 和 fetch.max.wait.ms 的配置不当。如果消费者拉取消息时，Kafka 里还没攒够足够的数据，消费者会一直等待，造成数据延迟。这个配置适合低延迟场景调小，适合高吞吐场景调大，没有绝对最优。

第三个是分区分配不均。有时候某个分区的数据量特别大，但该分区对应的消费者处理能力较弱，导致其他消费者都空闲，就这一个分区积压。这种情况要么重新设计分区 key，要么给关键分区单独配置消费者。

第四个是 broker 的磁盘或网络 IO 达到瓶颈。如果磁盘是机械硬盘，或者网络带宽打满，整个集群的性能都会下降。排查方式是用可视化监控看 broker 的磁盘吞吐、网络吞吐、CPU 使用率。

6.3 一次完整 lag 排查实录

我在项目里实际碰到过一次严重的 lag 告警。Kafka UI 里看到 ai-request-topic 的消费组 lag 高达 30 万，消息积压严重。

排查过程是这样的。第一步，我先确认生产端是否正常，查看 topic 的 LOG-END-OFFSET 增长速度，发现生产速度正常，说明数据正常流入。第二步，看消费组状态，发现消费者实例只启动了 2 个，而主题分区有 6 个，意味着有 4 个分区的消息无人消费，自然越积越多。第三步，查消费者日志，发现有两个消费者实例因为网络连接 broker 超时，被踢出了消费组，触发了 rebalance，但 rebalance 之后的分配出了问题。

原因找到后，解决就比较直接了。重启消费者应用，让所有实例重新加入消费组，重新分配分区。同时我把 Spring Kafka 的 session.timeout.ms 从默认的 45 秒调大到 90 秒，避免因为瞬时网络抖动导致频繁 rebalance。这里注意一点，session.timeout.ms 调大的代价是故障感知变慢，如果消费者真挂了，要等更久才能触发 rebalance，需要权衡。

经过这次排查，我养成了一个习惯：任何 Kafka 生产者都是消费者，任何消费者都是线上的一个故障源，做 AI 应用也不例外。宁可提前多配一点监控，也不要在线上积压几十万条消息再去补救。

7. Kafka 和 RabbitMQ 怎么选，以及面试常考点

7.1 Kafka 与 RabbitMQ 的核心区别

每次技术选型或者面试，Kafka 和 RabbitMQ 的区别都是热门话题。我自己两个都用过，简单说下使用感受。

从定位上说，RabbitMQ 是传统的消息中间件，更强调消息的可靠路由、灵活的消息确认机制和多种交换机模式，适合在微服务间做任务分发。Kafka 定位是分布式流处理平台，核心是日志的分布式存储和高吞吐流式处理，适合大数据场景、事件驱动架构和流计算。

吞吐量上，Kafka 设计的分布式日志存储让它能做到百万级每秒的吞吐，RabbitMQ 单机吞吐量通常只能到万级到十万级。这个差距在 AI 场景特别明显，大模型的日志流一天就是几十亿条，RabbitMQ 很难扛住。

消息保留策略上两者差别也大。RabbitMQ 的消息被消费后确认就会删除，Kafka 默认保留 7 天，哪怕消息已经被消费，还能通过重置 offset 重新消费。对 AI 场景来说，Kafka 这个能力真的很香，因为模型迭代训练需要回放历史数据，rabbitmq 做不到。

再加上 Kafka 自带的流式处理能力（Kafka Streams）、连接器生态（Kafka Connect），做流处理管道比 RabbitMQ 省力很多。

简单总结我的选型建议：单纯的任务队列、RPC 解耦，上 RabbitMQ，运维简单，社区资料多；大规模日志采集、事件驱动、数据管道、AI 数据供给，上 Kafka，吞吐量大、可重放、适合流式处理。

7.2 Kafka 面试高频题与启发性思考

结合我在招人过程中的考察点，整理一些高频面试题，这里也顺便给读者做个复盘。

第一题：Kafka 的架构中有哪些角色？Broker、Producer、Consumer、Consumer Group、Topic、Partition、Offset、Zookeeper/KRaft。这些基本概念必须能说清楚。

第二题：Kafka 为什么吞吐量高？要点是顺序写磁盘、页缓存机制、零拷贝技术、批量消息、分区并行。顺序写磁盘是 Kafka 最核心的设计，普通消息队列随机写，Kafka 利用磁盘顺序写的特性把性能提升了几个数量级。

第三题：Kafka 如何保证消息不丢？三端配合。生产者端 acks=all + retries；Broker 端设置副本因子大于 1 并且 min.insync.replicas 合理配置；消费者端关闭自动提交，处理成功后手动提交。

第四题：Kafka 的 offset 存在哪里？老版本存在 Zookeeper 里，新版本存在内部主题 __consumer_offsets 里。这个主题默认 50 个分区，和消费组数量有关。

第五题：什么是 Kafka 的 rebalance？消费者组内消费者数量变化或分区数量变化时，触发分区重新分配的过程。rebalance 期间消费会暂停，频繁 rebalance 是性能杀手。

第六题：Kafka 和 RabbitMQ 的区别是什么？我上面已经给了参考回答思路。面试时能结合具体业务场景说，比背概念好得多。

第七题：消息积压了怎么办？这是线上问题排查的核心。思路是，先确认积压发生在哪个环节，生产端还是消费端，然后考虑增加消费者实例、增加分区数、优化消费者处理逻辑、调整拉取参数。

我觉得面试题刷了再多，真正拉开差距的还是能不能结合项目实战把问题讲透。比如问他 Kafka 能重复消费吗，光说“能”没用，能把三种重复消费的场景和幂等设计讲清楚，才说明真的在项目里踩过坑。

8. 本地部署 AI 相关的一点延伸

热度词里还有一个方向值得提，就是本地部署 AI 和 Kafka 的结合。很多团队用 Ollama、vLLM 这类框架在本地起大模型服务，但本地推理服务的并发和稳定性都不太好控，加上 Kafka 做缓冲和异步化，是很自然的架构选择。

我简单写一个思路。本地模型推理服务起一个消费者，从 ai-inference-request 主题批量拉取推理请求，通过 HTTP 或者 gRPC 调用本地的大模型接口，拿到结果后再发到 ai-inference-response 主题。这样模型服务不用关心并发和排队，只需要保持稳定的处理速率即可。

另外一个细节是，本地部署 AI 模型时，模型加载和冷启动通常很慢，有的模型加载就要几十秒甚至几分钟。用 Kafka 做请求缓冲，用户在模型冷启动期间提交的请求都会安全地排队在 Kafka 里，模型加载完成之后继续消费处理，不会丢请求。这一点体验上的提升很明显，值得试试。

9. 实操心得与后续扩展

这次把 Kafka 接入 AI 链路，让我印象最深的一件事情是：技术选型的最大风险不是技术本身，而是团队对技术的使用模式不清晰。Kafka 接入 AI 听起来高大上，实际上就是解决数据如何可靠地从 A 点流向 B 点的问题。一旦你想通了 AI 应用的数据流本质是事件流，Kafka 的定位就非常自然。

踩过的坑也值得记录一下。一是 Docker 部署 Kafka 时 ADVERTISED_LISTENERS 配错导致客户端连不上，这个浪费了我半天时间；二是消费者组并发数大于分区数，导致部分线程空转，资源白白浪费；三是开启自动提交 offset 后出现过消息丢失，后来改成手动提交才解决。这些细节在官方文档里其实都有，但没踩过一遍就是记不深。

后续扩展的话，我打算在这个架构上做三件事。第一是把 Kafka Streams 引入来做 AI 日志的实时聚合分析，减少对离线计算任务的依赖；第二是把 Kafka Connect 用起来，直连数据湖和数据仓库，让 AI 场景的数据流转更自动化；第三是接一套完善的可观测体系，把 broker 指标、消费组 lag、延迟分位数全部接进监控大屏，实现可视化监控闭环。

用一句话总结我对 Kafka 接入 AI 的理解：AI 应用的核心是数据流，而 Kafka 是数据流最稳定的传送带。把这个基础打好，上面跑多少 AI 应用都踏实。