文档异步入库、分块上传与断点续传

面试回答

我们这条链路里，文件上传之后还要解析、分块和向量化，处理耗时比较长，所以需要把上传接口和后台任务解耦。我选择 Kafka，主要看中它的分区日志、消息保留和消费位点，任务失败后可以重新消费消息，消费者组也便于扩展处理能力。

上传完成后，系统发布文档入库任务，消费者根据数据库里的阶段状态继续处理。Kafka 负责消息传递和重放，具体恢复到哪一个阶段仍由业务 checkpoint 决定。RabbitMQ 也能完成这种异步任务，它的队列和路由语义更直接；我们这套方案更侧重消息重放和消费进度管理，因此使用 Kafka，并在业务侧补齐幂等和失败恢复。

面试回答

整体分成创建会话、上传分片、合并确认和触发入库几个阶段。用户发起上传后，后端先校验文件和权限，再向 MinIO 创建 Multipart Upload，拿到 uploadId。客户端按分片序号上传，保存每片的 ETag，Redis Bitmap 用来快速记录哪些分片已经完成。

网络中断后沿用原来的上传会话，先与 MinIO 的实际分片列表核对，再补传缺失部分，避免只相信缓存进度。全部分片上传成功后，后端按序号和 ETag 请求合并，并确认目标对象可用。之后在数据库中更新文档状态、写入 Outbox 事件，再由发布器投递 Kafka。后台完成解析、分块和索引后，文档才会标记为可检索。

面试回答

我按消息可能重复到达来设计消费逻辑，先用文档版本和处理阶段组成稳定业务键。消费者拿到消息后，先检查数据库里的阶段状态，已经完成的直接跳过，处理到一半的根据持久化 checkpoint 从未完成的位置继续。

对于最终的索引写入，我给每个子块生成稳定的 chunk ID，使用 upsert，重复处理时更新同一条记录，避免新增重复索引。每个阶段都在产物和状态落库后再提交消费进度。这样即使处理成功后提交位点失败，消息再次到达，也可以根据已有状态安全跳过。Redis 可以辅助加速判断，但持久化状态才是恢复依据。

面试回答

消费失败后，我先判断错误能否通过重试恢复。模型超时、存储暂时不可用这类临时故障采用退避重试；文件格式错误、内容为空这类确定性问题，继续重试没有意义，就记录原因，停止自动重试并转人工或死信流程。

恢复依赖数据库里的阶段 checkpoint。解析、分块和向量化各阶段完成后，先保存产物和状态，再提交消费进度。Worker 重启或者消息重放时，先读取已完成阶段，从失败位置继续，避免每次重新处理整个文件。重复到达的消息仍然走同一套幂等逻辑，所以重试和恢复可以配合使用。

面试回答

这里涉及数据库和 Kafka 两个系统，我使用 Transactional Outbox 保证任务不会因为发送失败而丢失。MinIO 文件合并确认成功后，在同一个数据库事务里更新文档状态，同时写入一条待发布事件，事务提交后再由独立发布器发送 Kafka。

Kafka 暂时不可用时，事件仍然保留在数据库，发布器后续继续重试；收到 Kafka 确认后才标记已发布。如果发送成功但标记前进程崩溃，事件可能再次投递，这部分交给消费端幂等处理。这样通过持久化待发布事件解决漏投递，通过幂等解决可能的重复投递。

面试回答

我先区分分片不完整、合并明确失败和合并结果不确定几种情况。合并前校验分片序号和 ETag，并和 MinIO 的分片列表核对；如果缺片，就保留上传会话，让客户端补传后再合并。

如果调用合并接口超时，不能直接认为文件没有生成。我会先查询目标对象，核对文件是否已经完整可用；已经成功就推进后续入库，确实未成功且原上传会话仍有效时再重试。会话已经失效就重新创建上传。只有确认原文件可用后才触发入库，失败过程中保留状态和原因，便于续传或清理遗留分片。