一定得用Kafka吗

不一定非得用 Kafka；是否需要消息队列，取决于任务规模、可靠性要求、解耦程度、失败补偿和吞吐压力。你之前“异步调用一个接口”的方案适合轻量异步场景，而这个文档处理链路用 Kafka 的价值在于可靠触发、削峰、解耦、多阶段流水线、失败重试和集群扩展。

你这个问题问得非常好，因为很多项目一提“前段轻、后段重”，就下意识上 Kafka、RabbitMQ、RocketMQ，但实际上异步任务不等于一定要消息队列。消息队列只是实现生产消费模型的一种方式，而且是偏“工程化、可扩展、高可靠”的方式。

你之前做 JSON 格式化和入库，前半段快、后半段慢，最后没有引入 MQ，而是异步调用一个接口，这个选择不一定错。关键要看当时的业务复杂度和可靠性边界。如果只是单机或少量服务、任务量不大、失败影响可控、没有复杂状态追踪，引入 Kafka 反而会增加部署、运维、监控、消费幂等、消息积压处理等成本。

但这个项目里的文档上传链路，和简单的 JSON 格式化入库相比，任务特征明显更复杂，所以 Kafka 的必要性会更强。

一、先明确：前段轻、后段重有哪些实现方式？

“前段轻，后段重”的本质是：请求线程不要阻塞在耗时任务上，先快速返回，后续慢慢处理。

这件事有很多实现方式，不只有 Kafka。

1. 请求内同步处理

最简单的是用户请求来了，Controller 直接处理到底：

上传文件 → 解析 → 切块 → 向量化 → 入库 → 返回

这种方式最简单，但缺点也明显：接口响应慢，容易超时，用户体验差，并发一高服务容易被拖垮。

文档解析、向量化、调用大模型、写 ES、写向量库这类任务都不适合同步做完。

2. 本地线程池异步处理

比如：

executor.submit(() -> {
    doHeavyTask();
});

或者用：

@Async

这种方式比同步好，接口可以快速返回。

但是它的问题是：任务只存在当前 JVM 内存里。如果服务重启，任务可能丢失；如果多实例部署，任务调度和状态管理也比较麻烦；如果任务失败，重试和补偿需要自己做；如果瞬间来了大量任务，线程池和内存可能被打爆。

它适合轻量任务，例如发送普通通知、短时间的日志加工、非核心异步处理。

3. 异步调用另一个接口

你之前采用的就是这种：

A 接口快速完成前置处理
然后异步 HTTP 调用 B 接口
B 接口执行慢任务

这种方案本质上也是生产消费，只不过“消息”不是发到 MQ，而是通过 HTTP 传过去。

它的好处是简单、直观、没有额外中间件。

但问题是，如果 B 接口调用失败怎么办？如果 B 服务短暂不可用怎么办？如果 A 调用了 B，但 B 处理到一半宕机怎么办？如果任务堆积，怎么排队？如果需要限流，怎么削峰？如果要重试，重试状态放哪里？如果有多个消费者，怎么均衡？这些都需要自己补。

所以异步 HTTP 调用适合链路简单、任务量不大、失败可接受或可以靠业务表补偿的场景。

4. 数据库任务表 + 定时扫描

还有一种很常见的方案：

前端请求 → 写 task 表 → 定时任务扫描 NEW 状态任务 → 执行处理

这其实是“用数据库当简易队列”。

它的优点是简单、可靠、容易查状态，任务不会因为服务重启而丢失。

缺点是实时性一般，扫描频率太低会延迟，扫描频率太高会增加数据库压力。并发抢任务时还要做锁控制，比如状态 CAS、分布式锁、SELECT FOR UPDATE SKIP LOCKED 等。

这个方案适合中等规模异步任务，比如订单超时关闭、报表生成、批处理导入等。

5. 消息队列：Kafka / RabbitMQ / RocketMQ

消息队列是更专业的生产消费模型。

它天然解决：

生产者和消费者解耦
任务排队
削峰填谷
多消费者扩展
失败重试
消息积压观察
跨服务异步通知

Kafka 尤其适合高吞吐、日志型、流水线型任务，比如文档处理、行为事件、日志采集、数据同步、索引构建等。

---

二、所以 Kafka 不是“必须”，但它解决的是更复杂的工程问题

你可以这样理解：

异步 HTTP：我直接叫另一个人去做事
数据库任务表：我把任务写在任务清单上，有人定时来领
Kafka：我把任务投递到专业传送带上，多个工人按规则消费

如果任务简单，用“直接叫人”就行。

如果任务需要可追踪、可重试，用“任务清单”就可以。

如果任务量大、阶段多、消费者多、需要削峰和解耦，就更适合 Kafka。

三、你之前的 JSON 格式化和入库为什么可以不用 MQ？

你之前的场景是：

前半段快
后半段慢
后半段做 JSON 格式化和入库

如果这个任务有这些特点：

数据量不大
处理逻辑简单
只有一个后置服务
失败后可以重调接口
不要求非常严格的任务状态
不需要多个消费者并行扩展
不需要保留事件流
不需要多阶段处理

那不引入 Kafka 是合理的。

因为引入 Kafka 不只是加一个依赖这么简单，它还会带来很多工程成本：

Kafka 集群部署和维护
Topic 规划
消费者组配置
消息序列化
消费幂等
失败重试
死信或补偿
消息积压监控
消费延迟监控
重复消息处理
顺序性处理

如果业务规模没到，确实会显得“重”。

所以你的判断是对的：不是所有生产消费模型都值得上消息队列。

四、那这个文档上传链路为什么更适合 Kafka？

这个项目的上传链路后面不是一个简单慢任务，而是一条比较长的异步流水线：

文档上传
→ Tika 解析
→ 文本抽取
→ 文档结构识别
→ 切块策略推荐
→ 用户确认
→ 父子块切分
→ 向量化
→ 写入向量库
→ 写入 Elasticsearch
→ 写入 Neo4j
→ 更新文档状态
→ 记录任务日志

这和“JSON 格式化后入库”不是一个复杂度。

这里用 Kafka 的价值主要体现在下面几个方面。

---

五、好处一：解耦上传接口和后续处理链路

上传接口只需要负责：

校验文件
上传 MinIO
创建文档主记录
创建任务记录
发送 Kafka 消息
返回 documentId 和 taskId

它不需要知道后面具体怎么解析，也不需要关心：

Tika 解析怎么做
切块策略怎么推荐
向量化用哪个模型
索引写入哪些数据库
失败怎么重试

上传接口和处理服务之间通过 Kafka 消息解耦。

这样以后如果你要改后续处理逻辑，例如从 Apache Tika 换成其他解析器，或者新增 OCR 处理、图表解析、摘要生成，不需要改上传接口，只需要改消费方。

这就是架构上的解耦。

六、好处二：避免上传接口被慢任务拖垮

文档处理任务可能非常慢。

比如一个大 PDF：

下载原始文件：几百毫秒到几秒
Tika 解析：几秒到几十秒
LLM 切块推荐：几秒
向量化：几秒到几十秒
ES 和向量库写入：几秒
Neo4j 图谱构建：几秒

如果这些都在上传接口里做，用户可能要等几十秒甚至几分钟。

更麻烦的是，并发一高，Tomcat 请求线程会被占满，后续用户连上传接口都进不来。

Kafka 可以让上传接口快速结束，把重任务交给后台消费者慢慢处理。

---

七、好处三：削峰填谷，保护后端处理能力

假设上午 9 点，企业用户批量上传了 500 份文档。

如果没有 Kafka，上传接口直接异步调用处理接口，那么处理服务可能瞬间收到 500 个请求。Tika、向量化模型、ES、向量库、Neo4j、数据库都可能被打爆。

Kafka 的作用是中间缓冲：

上传服务快速生产消息
Kafka 暂存消息
消费者按自身能力慢慢消费

比如你可以配置 5 个消费者实例，每次只处理一定数量的任务。即使用户瞬间上传 500 份文档，后端也不会被瞬间压垮，只是 Kafka 里出现一定积压，系统可以慢慢消化。

这就是削峰填谷。

异步 HTTP 调用也可以做限流，但你需要自己实现排队、重试和积压管理；Kafka 是天然做这个的。

---

八、好处四：支持消费者横向扩展

文档处理是典型的可以并行处理的任务。

不同文档之间基本互不影响，所以可以多个消费者一起处理：

Consumer-1 处理文档 A
Consumer-2 处理文档 B
Consumer-3 处理文档 C

Kafka 的消费者组机制可以天然支持这一点。

当任务量上来时，你可以增加消费者实例，提高处理能力。

比如：

一台消费者：每分钟处理 10 个文档
三台消费者：每分钟处理 30 个文档
五台消费者：每分钟处理 50 个文档

当然实际吞吐还取决于 Tika、LLM、数据库、向量库等瓶颈，但 Kafka 至少提供了水平扩展的基础。

如果是异步调用接口，你也可以扩容后置服务，但任务分发、失败重试、负载均衡、积压可见性就需要额外设计。

---

九、好处五：消息持久化，服务重启后不容易丢任务

本地线程池异步最大的问题是任务在内存中。

服务一重启，没执行完的任务可能就没了。

Kafka 消息是持久化的。只要消息已经成功写入 broker，即使消费者服务挂了，后面恢复后也可以继续消费。

在你的上传链路里，发送 Kafka 是同步等待确认的：

kafkaTemplate.send(topic, key, payload).get();

这意味着上传接口返回成功前，系统确认 broker 已经收到消息。

相比异步 HTTP，“对方接口收到没有、处理到哪一步、失败后怎么补”都更可控。

---

十、好处六：失败重试和补偿更容易设计

文档处理链路很容易失败。

例如：

MinIO 下载失败
文件格式异常
Tika 解析失败
大模型调用超时
向量化失败
ES 写入失败
Neo4j 写入失败
数据库更新失败

用了 Kafka 后，消费失败可以有几种处理方式：

消费端捕获异常，更新任务状态为 FAILED
根据 retryCount 判断是否重试
延迟后重新投递
超过次数进入失败状态或死信队列
由后台管理页面人工重试

当然，Kafka 不会自动帮你解决所有业务失败，消费幂等、任务状态、重试次数还是要自己设计。但 Kafka 给你提供了“任务可重新消费、消息可积压、消费者可恢复”的基础能力。

在这个项目文档里，也有任务表和任务日志：

taskStatus
currentStage
retryCount
taskLog

这说明它不是只依赖 Kafka，而是：

Kafka 负责触发和传递
数据库任务表负责状态和可观测
任务日志负责追踪
补偿任务负责兜底

这是比较稳的设计。

---

十一、好处七：适合多阶段流水线扩展

你的项目不是只有一个上传后的任务。后续可能会拆成多个阶段：

parse-route-topic
document-parse-topic
chunk-strategy-topic
chunk-build-topic
embedding-topic
index-build-topic
summary-topic
graph-build-topic

也就是说，一个阶段完成后，可以再发下一个阶段的消息。

比如：

上传完成 → 发解析路由消息
解析完成 → 发切块策略推荐消息
用户确认 → 发切块构建消息
切块完成 → 发向量化消息
向量化完成 → 发索引构建消息

这种多阶段处理天然适合消息队列。

如果用异步 HTTP，一开始还能接受；但阶段越来越多后，服务之间会形成复杂调用链：

A 调 B
B 调 C
C 调 D
D 调 E
E 调 F

这会让链路耦合变重，而且某个服务失败会影响调用链。

消息队列可以把它变成事件驱动：

A 完成后发事件
谁关心这个事件，谁消费

可扩展性更好。

---

十二、好处八：同一文档顺序性更容易控制

文档处理有些阶段对顺序有要求。

比如同一个 documentId，不能索引还没构建完又重复触发另一个构建任务，或者切块还没完成就开始向量化。

项目中 Kafka 发送时用了：

String.valueOf(message.getDocumentId())

作为消息 key。

Kafka 会让相同 key 的消息进入同一个 partition，从而在同一 partition 内保持顺序消费。

这对于同一文档的多阶段事件很有价值。

当然，这不是说 Kafka 能自动保证所有业务顺序，业务上仍然要用任务状态做校验。例如消费方收到“构建索引”消息时，要检查当前文档是否已经完成切块。但 Kafka 的分区顺序性可以降低乱序概率和处理复杂度。

---

十三、好处九：便于做监控和运维

Kafka 有天然的消费位点和积压概念。

你可以观察：

某个 topic 有多少消息积压
某个消费者组消费到哪里了
消费延迟是多少
哪个 partition 堆积严重
消费者是否掉线

对文档处理这种后台任务很重要。

比如用户反馈：

我上传文档后一直显示解析中

你可以排查：

文档主表状态是不是 PARSING
任务表是不是 NEW
Kafka 消息是否发送成功
topic 是否有积压
consumer 是否在线
taskLog 是否有失败记录

如果不用 MQ，而是异步 HTTP 调用，除非你自己做完整日志、任务表、调用链追踪，否则排查会更麻烦。

---

十四、但是 Kafka 也不是没有代价

你感觉它“过重”，这个感受是准确的。

Kafka 的成本主要包括：

需要部署和维护 Kafka
需要设计 topic
需要管理消费者组
需要处理消息重复消费
需要保证消费幂等
需要处理消息积压
需要监控 broker 和 consumer
需要设计失败重试和死信机制
需要考虑消息顺序和分区策略

而且 Kafka 本身只保证消息层面的能力，不会自动保证你的业务最终成功。

例如消费者可能收到同一条消息两次，所以你必须做幂等：

同一个 taskId 已经处理成功，就不要重复处理
同一个 documentId 已经生成索引，不要重复插入脏数据
更新状态时要检查前置状态是否合法

所以 Kafka 适合复杂任务，但也确实会提高系统复杂度。

---

十五、怎么判断要不要上 Kafka？

可以用一个很实用的判断标准。

适合不用 Kafka 的情况

如果你的任务满足这些条件，就可以先不用 MQ：

任务量小
处理步骤少
只有一个消费者
失败影响不大
接口调用失败可以简单重试
不要求强可观测
不需要削峰
不需要多服务解耦
没有明显积压问题

例如你说的 JSON 格式化和入库，如果只是把数据格式化后写库，后置任务不复杂，用异步接口、本地线程池、数据库任务表都可以。

适合用 Kafka 的情况

如果任务满足这些条件，就更适合引入 MQ：

任务耗时长
任务量可能突增
后续处理阶段多
需要多消费者并行
需要服务解耦
需要失败重试
需要任务积压能力
需要较强可观测性
需要跨服务事件驱动
未来有扩展更多消费方的可能

文档处理链路明显属于这一类。

---

十六、这边 Kafka 的“必要性”可以怎么讲？

不要把 Kafka 讲成“异步任务必须用 Kafka”，这样容易被面试官追问。

更好的说法是：

Kafka 不是实现异步的唯一方式。对于简单后置任务，异步 HTTP、本地线程池或数据库任务表都可以解决。但这个项目的文档处理链路具备任务耗时长、阶段多、并发上传可能突增、需要失败重试、需要状态追踪、需要多消费者扩展等特点，所以引入 Kafka 作为异步任务触发和削峰缓冲组件。上传接口只负责文件接入和任务初始化，Kafka 负责把后续解析任务可靠地交给后台消费方处理，从而实现上传链路和解析链路解耦。

这段表达比较稳。

十七、结合上传接口讲 Kafka 的真实价值

在这个上传接口里，Kafka 不是为了“显得高级”，而是为了把系统拆成两个边界清晰的部分：

上传服务边界：
接收文件、存 MinIO、建文档记录、建任务记录、发消息、返回

异步处理边界：
消费消息、查文档、下载文件、解析、切块、向量化、建索引、更新状态

也就是说，Kafka 是两个边界之间的“可靠事件通道”。

如果不用 Kafka，而是上传接口异步调用解析接口，也能跑，但会有几个问题：

解析接口短暂不可用时，上传侧怎么处理？
瞬间上传很多文件时，解析服务怎么承压？
解析服务扩容后，任务怎么均匀分发？
解析任务失败后，谁负责重试？
任务堆积在哪里可见？
后续新增图谱构建、摘要生成等消费方时，上传接口是否还要改？

Kafka 正是用来解决这些工程问题的。

---

十八、这个项目中 Kafka 和任务表是互补关系

这里还有一个非常关键的点：不是用了 Kafka，就不需要任务表。

Kafka 和数据库任务表职责不同。

Kafka 负责：

通知有任务要处理
缓冲任务压力
分发任务给消费者
支持消费者恢复

任务表负责：

记录任务业务状态
记录当前处理阶段
记录重试次数
支持前端查询进度
支持后台补偿扫描
支持问题排查

所以这个项目采用的是：

MySQL 任务表 + Kafka 消息触发 + 任务日志追踪

而不是只靠 Kafka。

这比单纯 MQ 更可靠，也比单纯数据库扫描更实时。

完整逻辑是：

上传时先写任务表
事务提交后发 Kafka
消费者收到 Kafka 后处理任务
每个阶段更新任务表和任务日志
如果 Kafka 发送失败或消费异常，由任务表补偿扫描兜底

这个设计是比较成熟的。

十九、如果不用 Kafka，这个项目可以怎么做？

理论上也可以不用 Kafka。

可以设计成：

上传接口写入 document 表和 task 表
后台定时任务每隔几秒扫描 NEW 状态任务
抢占任务后执行解析
执行完成后更新状态
失败后增加 retryCount

这种方式完全可行，甚至很多中小系统就是这么做的。

但它的缺点是：

实时性取决于扫描间隔
任务量大时数据库扫描压力增加
多实例抢任务需要锁或状态 CAS
任务分发不如 Kafka 自然
无法很好削峰
消费积压不如 MQ 直观

所以如果是早期 MVP 或任务量小，用数据库任务表扫描可以；如果系统已经是企业知识管理平台，后续文档解析、切块、向量化、索引是核心链路，那用 Kafka 更合适。

二十一、这块你可以形成一个面试级回答

如果面试官问：

这种异步任务为什么要用 Kafka？直接异步调用接口不行吗？

你可以这样回答：

直接异步调用接口当然可以，它适合处理链路简单、任务量不大、失败影响可控的场景。我之前也在类似 JSON 格式化和入库场景中采用过异步接口调用，因为当时引入 MQ 的成本高于收益。

但这个项目的文档处理链路更复杂，上传后会进入 Tika 解析、切块策略推荐、父子块切分、向量化、ES 和向量库索引、Neo4j 图谱构建等多个阶段，任务耗时长且容易出现并发上传峰值。因此我这里引入 Kafka，主要是为了实现上传链路和处理链路解耦，同时利用 Kafka 做削峰填谷、消息持久化、多消费者扩展和失败恢复。

另外，不是只依赖 Kafka，而是配合任务表和任务日志使用。上传接口先在事务内写入文档主表、任务表和任务日志，事务提交后再发送 Kafka 消息。Kafka 负责触发处理，任务表负责状态追踪和补偿兜底。这样既保证了异步处理能力，也方便前端查询进度和后台排查问题。

这个回答很完整，而且不会显得你“为了用 Kafka 而用 Kafka”。

---

二十二、最核心的判断结论

你可以记住这句话：

轻量异步可以用线程池、异步 HTTP 或数据库任务表；复杂异步流水线才值得引入 Kafka。Kafka 的价值不只是“异步”，而是“可靠解耦、削峰缓冲、持久化、多消费者扩展和可观测消费”。

对应到这个项目：

上传接口：前台快速接收和登记
Kafka：可靠触发异步解析流水线
任务表：记录业务状态
任务日志：支撑可观测
补偿机制：兜底消息失败或消费失败

所以 Kafka 在这里不是唯一解，但它是更适合这个项目复杂度和扩展性的解。

---

企业级项目导航：⬅️ 01-Kafka 消费与文本内容解析 | 02-一定得用Kafka吗 | ➡️ 03-上传接口与文档主记录创建