分片上传+断点续传
- 前端先把大文件切成小的分片，比如 5MB 一块，然后并发地上传到后端。后端每收到一个分片，就存到 MinIO 中，同时会用 Redis 的 bitmap 去记录哪些分片已经上传成功。这样的好处就是，即使上传过程中断了，前端可以根据 Redis 状态判断哪些分片已经上传，不用从头开始（这个就是断点续传），用户体验会比较好。
- 首次上传分片时，我们会把这个文件的元信息，比如文件名、文件大小、上传者、所属组织标签等，保存到 MySQL 中，用来跟踪整个文件的上传状态。这也是为了方便后续的状态管理和权限控制。
- 当所有分片上传完成后，前端会调用后端的合并接口。这里我们用的是 MinIO 提供的 composeObject 功能，直接在存储端完成分片的合并，完全不占用服务器的内存和 CPU 资源。合并完成后，系统会把文件状态在 MySQL 里更新为‘已完成’，并且清理掉对应的分片文件和 Redis 记录。
- 文件合并后我们还会发送一条 Kafka 消息，通知后台的异步服务去做后续的文件解析、文本切片、向量化等工作，保证上传接口本身是快速响应的，不会因为后端的耗时任务拖慢用户体验。
- 前端在上传文件前，会通过 MD5 算法计算出该文件内容的唯一哈希值，也就是 fileMd5，然后前端在分片上传文件时，请求不仅会包含分片本身的数据，还会附带两个关键的元信息，一个是 fileMd5，一个是 chunkIndex（表示当前索引位置），用于记录当前分片在原始文件中的顺序。等前端把所有分片都传完了，后端再根据这个 fileMd5 把所有分片拿出来，按 chunkIndex 顺序拼接在一起，通过 MinIO 的 composeObject 方法直接在存储端完成合并
文件合并过程中如何保证原子性
- 合并步骤是调用了 MinIO 的 composeObject 接口。这个操作是在 MinIO 服务端内部完成的，它本身是一个原子操作。这意味着，对于 MinIO 来说，分片合并要么就彻底成功，生成一个完整的最终文件；要么就失败，不产生任何文件。
- 合并操作失败：MinIO 没有生成新文件，代码会抛出异常并终止。此时，分片、数据库记录、Redis 缓存都还保留在合并之前的状态，用户只需要重新触发合并即可。
- 整个上传流程是基于 JWT 做身份认证的，所有接口，比如分片上传、合并操作，前端都必须带上 token。这个 token 在后端被拦截器解析之后，会提取出当前用户的 userId。然后我们在用户第一次上传分片时，就把这个 userId 和文件的 MD5、文件名等信息一起写进数据库，保存到 file_upload 表里。这个过程其实就明确了：这个文件是属于谁的。
- 接下来，比如合并文件这种敏感操作，系统会再做一次权限校验。我们会通过 fileMd5 + userId 去数据库查这个文件记录，确认这个操作确实是这个用户发起的，防止用户去合并别人的文件。
为什么选择Kafka异步处理
- 第一，比如说我们在文件上传完成之后，会有很多后续的异步任务，比如提取元数据、生成全文索引、做 AI 向量化之类的处理，Kafka 本身就非常适合这种高吞吐的数据流
- 另外一个很关键的点是 Kafka 的数据持久化能力。它的消息是保存在磁盘上的，而且可以保留很久，比如 7 天。消费者通过 offset 去控制消费进度。这个机制带来了一个特别大的好处：我们可以随时进行数据回溯。