RAG智能问答系统——文件上传与解析模块 （面试）

总结了整个流程可以帮助我理清整个模块到底做了什么也能根据各个流程具体定位源码方便深入理解和优化。一、大文件上传 异步处理全流程文字化完整版1. 前置准备与文件分片用户选择大文件后前端先做基础校验限制文件大小、类型再通过 Web Worker 异步计算整个文件的 MD5fileMd5避免阻塞页面。同时将文件按 5MB 大小切分成多个分片最后一个分片保留实际大小、不补零。每个分片会附带自身的 MD5chunkMd5并携带fileMd5标识所属文件和chunkIndex标识分片顺序。2. 分片上传与断点续传前端按最多 5 个分片并发上传避免浏览器请求数超限。上传前先请求后端接口通过 Redis Bitmap 查询该fileMd5对应的已上传分片状态跳过已上传分片仅上传缺失部分实现断点续传。上传过程中若网络中断前端会监听离线事件暂停上传重连后自动查询已上传分片状态从断点继续上传。若后端服务短暂不可用前端会按指数退避策略重试 3 次仍失败则提示用户待服务恢复后自动续传。3. 后端分片接收与存储后端收到分片后先做多层校验校验chunkIndex合法性、分片大小是否符合规则校验用户权限确保归属正确的组织标签对比前端传入的chunkMd5与后端重新计算的结果拒绝被篡改或损坏的分片。校验通过后将分片存储到 MinIO路径为chunks/{fileMd5}/{chunkIndex}同时用 Redis Bitmap 标记该分片为已上传以fileMd5为 Key每个分片对应一个 bit 位。首次上传分片时后端会将文件元信息文件名、总大小、上传者、组织标签、上传状态存入 MySQL用于后续状态跟踪与权限控制若文件记录已存在则校验元信息一致性防止 MD5 碰撞或数据篡改。4. 分片合并与资源清理所有分片上传完成后前端调用合并接口。后端会加分布式锁防止并发合并将文件状态更新为「合并中」校验分片完整性从数据库查询所有分片并按chunkIndex升序排列核对分片总数与 MinIO 中分片文件是否存在调用 MinIO 的composeObject方法在存储端直接合并分片不占用应用服务器内存与 CPU校验合并后文件的大小与 MD5确保与前端传入的fileMd5一致合并成功后更新 MySQL 中文件状态为「已完成」异步清理 MinIO 中的临时分片文件、Redis 中的 Bitmap 状态若合并失败重置文件状态并记录异常由前端重试或定时任务校准。5. 异步处理与最终一致性合并完成后后端发送 Kafka 事务消息触发后续文档处理流程消费者从 MinIO 流式下载文件用 Apache Tika 解析文本对文本做语义分块调用向量 API 生成向量后存入 Elasticsearch若向量化失败自动降级为纯文本存储消费失败的任务会进入死信队列等待人工干预重试。为保障最终一致性系统会定时执行校准任务每小时扫描「合并中」状态的文件校验 MinIO 中是否存在合并后的文件自动修正状态每天清理超过 7 天的未合并分片与无效 Redis 状态每周对账 MySQL 元数据与 MinIO 存储清理不一致数据。二、核心组件职责文字总结前端负责文件分片、MD5 计算、并发上传控制、断点续传逻辑与异常重试MinIO存储临时分片与最终合并文件在服务端完成分片合并不占用应用服务器资源Redis Bitmap记录分片上传状态支撑断点续传内存占用小、读写速度快MySQL存储文件元信息、上传状态与权限数据作为状态真相源Kafka解耦上传与文档解析流程实现削峰填谷保证任务不丢失定时任务清理无效分片、校准状态不一致数据保障系统整洁与数据一致。后面要详细理解Kafka如何实现异步解耦如何保证消息可靠的消费者重试和死信队列机制相对于RabbitMQ的优缺点。感觉源码还是得看看优化的方向应该是整体业务流程中数据的一致性与挑战保证原子性。