上传接口阶段一前端分片与“指纹”识别Gateway在处理 GB 级别的文档时传统的单文件上传会导致连接超时或内存崩溃。预处理MD5 计算前端利用spark-md5预先扫描文件生成FileMD5。这是文件的“身份证号”用于实现秒传如果后端已存该 MD5直接返回成功。物理切片Slicing利用 JavaScript 的Blob.slice()将大文件切割为固定大小如 5MB的Chunks。并发上传前端同时发起多个uploadChunk请求携带chunkIndex和fileMd5。阶段二后端接入与可靠性保障Warehouse后端不仅要收数据还要做精密的状态管理。二级校验Redis MySQLRedis作为高性能计数器记录已到达的分片编号实现高并发下的快速判重。MySQL持久化文件元数据文件名、总大小、上传者、组织权限。断点续传逻辑如果上传中断用户下次上传同一 MD5 文件时后端通过查询 Redis/MySQL 返回已收到的chunkIndex前端从断点处继续发送。云端合并MinIO当所有分片到齐后端调用 MinIO 的composeObject接口进行服务端合并避免将几十 GB 的数据拉回应用服务器内存。阶段三任务调度与异步解耦Assembly Line文件存入 MinIO 只是开始真正的“重型加工”必须异步化。任务下发Kafka后端合并完成后立即向 Kafka 发送一条包含fileMd5和objectUrl的事务消息。削峰平谷Kafka 充当了缓冲池。即便用户瞬间上传了 1000 份文档后台的Consumer消费者也会按照自身算力CPU/内存情况有序地领取任务防止系统宕机。存算分离Web 服务器只负责“收货”解析任务交给专门的“加工服务器”。阶段四文档解析与语义切片Alchemy这是 RAG 系统区分于传统网盘的关键点目标是将非结构化数据转化为“AI 易读”的格式。流式下载与解析Consumer 收到消息后从 MinIO 拉取流式数据利用Apache Tika等工具提取纯文本。注意避免将大文件一次性加载进内存应使用磁盘临时目录作为缓冲区。语义切片Chunking将提取的长文本切分为小段如 500-800 Token。重叠度Overlap相邻切片需保留 10%~20% 的重复内容确保语义在切断处不丢失。语义边界优先按段落、标题、句号进行物理切割。阶段五向量化与知识入库Indexing将文字转化为数字存入搜索引擎。Embedding 向量化将每一个 Chunk 喂给 Embedding 模型如 OpenAItext-embedding-3或本地模型得到一串固定长度的高维浮点数组。索引构建Elasticsearch将[原始文本, 向量数组, 元数据]存入 ES。ES 底层利用HNSW 算法构建导航图索引实现毫秒级的语义近似搜索。状态闭环全部入库完成后更新 MySQL 中的文件状态为SUCCESS用户此时即可在界面上看到“文档已就绪”。MysqlRedisElasticsearchminIO如何协同工作保证一致性系统通过 MySQL 中的status字段强制约束各组件的动作。状态语义潜在冲突 / 异常情况解决策略 (自愈机制)0: INIT任务初始化未开始上传孤儿分片MinIO 存在该 MD5 文件夹但 MySQL 仅停留在 INIT。定时任务清理扫描 MinIO 临时目录若 MySQL 记录为 INIT 且超时物理删除 MinIO 数据。1: UPLOADING分片上传中计数不一致前端重试导致 Redis 计数 实际分片数或分片丢失导致无法合并。幂等计数Redis 记录已上传的chunkIndex集合而非单纯累加定时任务检查超时未完成的任务。2: MERGING合并触发中并发合并两个请求同时发现分片到齐触发两次 MinIO 合并请求。分布式锁 状态前置检查使用 RedisSETNX锁定fileMd5执行合并前必须确认状态仍为 UPLOADING合并开始瞬间更新为 MERGING。3: PROCESSING任务已发 Kafka解析中丢失任务MySQL 状态为 PROCESSING但 Kafka 消费失败或消费者宕机。超时重推定时任务扫描超过 30 分钟仍处于 PROCESSING 的记录重新投入 Kafka 队列补偿机制。4: SUCCESSES 索引完成数据残留MySQL 已成功但 MinIO 临时分片未清理占用空间。后置清理状态改为 SUCCESS 后触发异步删除 MinIO 临时分片若失败由垃圾回收 Job 兜底。5: FAILED处理失败脏数据堆积ES 中存了部分向量MinIO 存在合并后的文件。物理抹除状态转为 FAILED 时根据fileMd5同步删除 ES 相关索引及 MinIO 物理文件。1. 逆向校对策略 (Backward Reconciliation)原则MinIO/Redis/ES 的数据必须在 MySQL 中找到“合法身份”。执行定时任务Reconciliation Job以存储侧MinIO/ES为基准扫描。如果MinIO 有文件而MySQL 无记录/状态为 INIT→\rightarrow→物理删除MinIO 文件。如果ES 有向量而MySQL 状态非 SUCCESS→\rightarrow→物理删除ES 向量。2. 状态原子性与可见性先写库后动作在调用 MinIO 合并或发送 Kafka 消息前必须先在数据库中完成状态变更。CAS (Compare And Swap)更新状态时使用 SQLUPDATE file_table SET status 2 WHERE file_md5 xxx AND status 1。利用数据库行锁防止并发冲突。3. 消费者幂等性冲突Kafka 消息重复消费导致重复解析。解决ES 写入使用fileMd5_chunkIndex作为文档 ID。无论解析多少次ES 始终执行Overwrite覆盖而非Append追加保证最终向量数据的一致性。混合检索接口阶段一权限画像与查询语义化在检索开始前系统首先确定“谁在搜”以及“搜什么”。语义向量化利用 Embedding 模型将原始提问Query转化为高维向量。文本分析与提取利用分词器将整个句子切分为词组双路准备此时系统手中同时持有查询向量用于语义搜索和原始关键词用于文本搜索。阶段二向量召回与强过滤这是检索的“漏斗”入口核心是语义找近邻权限做隔离。向量召回 (KNN)在向量空间中寻找语义最接近的 topN 个片段。这解决了“意思相近但词不同”的问题。硬性权限过滤 (Filter)这是一个“一票否决”环节。系统强制要求结果必须满足是我的文档OR是公开文档OR是我组织的文档。不满足条件的片段即使语义再接近也会被剔除。阶段三关键词召回与分数融合向量检索虽然聪明但有时会产生语义幻觉词不达意。本阶段通过重排纠偏。关键词二次打分对召回的候选片段进行传统的文本频率算法BM25打分。分数加权融合给语义分向量分配权重。给关键词匹配分文本分配权重。逻辑目标确保那些既符合语义又含有精确关键词的片段能够排在最前面。阶段四结果装配与元数据溯源将 ES 检索到的“数字碎块”还原为用户可读的结构化信息。由于向量数据库ES主要负责高性能检索并不适合存储频繁变动或详尽的业务属性因此需要此阶段进行“数据对账”。数据映射利用 ES 检索结果中的fileMd5回查MySQL。将哈希值还原为真实的文件名称。这实现了存算分离即使文件在数据库中改名也无需重新计算向量。属性补全将 ES 中的权限 ID如userId,orgTag转换为可读的业务标签如上传者姓名、所属部门。这为前端展示提供依据也为大模型LLM提供准确的引用出处Citation。如果是模型对话功能片段截取对文本进行清洗去乱码/换行并按需截断。确保提供给大模型的上下文Context既精炼又高质有效节省 Token 消耗并提升回答准确度。阶段五功能分流与生成增强根据用户的业务需求决定最终数据的去向判断当前请求类型。若为搜索功能则直接将阶段四封装好的结构化列表返回给前端展示带权限的文件片段。上下文拼接若为模型对话则将多个检索片段按相关性顺序进行文本串联形成增强知识背景。提示词增强 (RAG)将拼接好的背景知识与用户原始提问填入预设的Prompt 模板调用大模型LLM接口并将生成的回复以SSE 流式Streaming或 WebSocket实时推送到前端。