Day1学习笔记 --AIAgent 项目 --文件上传与解析（一）
学习内容：
基于MinIO搭建对象存储承载大文件上传，实现大文件分片上传与断点续传，优化后 1GB 文件上传耗时由 15s 降至 3s。
一、MD5算法
1、概念
MD5是一种哈希算法（也叫散列算法），核心作用是把任意长度的输入数据（如字符串、文件、二进制流），通过特定计算规则，生成一个固定 128 位（16 字节）的哈希值（通常以 32 位十六进制字符串形式展示）。
我们可以用一个通俗的比喻理解：
- 就算是把一篇 1 万字的文章（任意长度输入）交给 MD5 “机器”，它也会输出一个固定长度的 “指纹”（32 位十六进制字符串）；
- 哪怕只改文章里的一个标点，输出的 “指纹” 也会完全不同；
- 但你无法通过这个 “指纹” 反推出原来的文章内容。
2、核心特性
- 固定长度输出：无论输入是 1KB 的文件还是 1GB 的视频，MD5 结果都是 32 位十六进制字符串（如
e10adc3949ba59abbe56e057f20f883e）； - 雪崩效应：输入的微小变化（哪怕 1 个字符），会导致输出的哈希值完全不同；
- 不可逆性：无法从 MD5 哈希值反推原始数据（这也是它早期用于密码加密的核心原因）；
- 易计算：对任意输入，能快速算出对应的 MD5 值。
3、适用场景
1）文件完整性校验
在下载软件或者安装包时，官网一般会提供一个该文件的MD5值，我们下载后计算文件MD5值，如果一致，则表示文件未被篡改，无传输错误；如果不一致，那么文件可能被篡改或者下载错误。
2）数据唯一标识
在MinIO/文件存储场景中，常用MD5算法给文件命名：
- 避免文件名重复，（如果用户上传的是同名图片，可以用MD5作为唯一Key存储）
- 可以快速判断文件是否存在，（计算新文件的MD5，如果存储中已有，则无需重复存储）
二、传统文件存储方式与改进
以前的做法是：专门开一台集中式文件服务器，里边存文件，用Tomcat对外访问
现在的做法是：使用MinIO存储对象，数据库存路径，是分布式对象存储
1、MinIO分布式对象存储的概念
MinIO是分布式对象存储系统，专门用于存储海量的非结构化的数据（图片，视频，文档，日志文件等）。
传统文件服务器是类似于单间仓库，仓库坏了就都没了，但是MinIO的关键在于分布式模式，这种是多间联网的仓库集群，文件会被拆分到多间仓库，即使一间坏了，数据也可以从其他仓库恢复，且多间仓库可同时对外提供服务，效率高。
2、两者区别与比较
| 维度 | 传统文件服务器（Tomcat + 集中式服务器） | MinIO 分布式对象存储 |
|---|---|---|
| 存储架构 | 集中式：所有文件存在单台服务器的本地磁盘 | 分布式：数据分散存储在多台服务器节点，支持集群部署 |
| 高可用性 | 极低：服务器宕机 / 磁盘损坏，所有文件不可用 / 丢失 | 极高：多副本备份（可配置 1-16 副本），部分节点故障不影响数据访问，支持自动恢复 |
| 扩展性 | 差：扩容需更换更大磁盘 / 服务器，停机维护 | 好：线性扩容，直接添加新节点即可，无需停机，存储容量随节点数增长 |
| 并发性能 | 低：单台服务器的 CPU / 网卡 / 磁盘 IO 是瓶颈，高并发下易卡顿 | 高：集群节点并行处理请求，分摊压力，支持海量并发读写 |
| 数据管理 | 依赖操作系统文件系统（如 NTFS/Ext4），手动管理文件夹 / 权限，易出现文件重名、路径混乱 | 基于对象存储模型，自带权限控制、版本管理、元数据管理，可通过 API 统一管控 |
| 访问方式 | 主要通过 Tomcat 提供 HTTP 访问，需自己开发文件上传 / 下载接口，适配性差 | 兼容 S3 协议，提供标准化 API/SDK/ 工具，支持 HTTP/HTTPS，可直接对接各种业务系统（Java/PHP/Python 等） |
| 运维成本 | 高：需手动备份、监控单台服务器，故障恢复慢 | 低：自带监控、自动容错，故障节点替换后自动同步数据，运维更轻量化 |
| 适用场景 | 小型系统、低并发、少量文件存储（如内部管理系统） | 中大型系统、高并发、海量非结构化数据（如电商、短视频、日志存储） |
三、分片上传时用什么作为文件的唯一标识
困惑：为什么使用的是MD5算法，而不是原来用于给文件名称命名时生成的uuid算法，其区别对比如下：
1、MD5与UUID的核心特性对比
| 维度 | MD5 | UUID（如 UUID4） |
|---|---|---|
| 生成依据 | 基于文件内容（内容相同则值相同） | 基于时间 / 随机数（和内容无关） |
| 核心特性 | 内容唯一 → MD5 唯一 | 全局唯一（ 但和内容无关） |
| 长度 | 32 位十六进制字符串（短小） | 36 位字符串（含-，更长） |
| 可预测性 | 相同文件可预测 MD5 值 | 完全随机，不可预测 |
| 核心用途 | 内容校验、文件指纹、去重 | 分布式系统唯一 ID、主键 |
2、为什么分片上传场景下不能用UUID代替MD5？
1. 核心问题：无法实现文件去重
- 假设用户上传同一个文件（比如
test.zip）两次：- 用 MD5：两次生成的 MD5 完全相同，后端能识别出 “这是同一个文件”，直接返回已上传结果，无需重复存储；
- 用 UUID：两次生成的 UUID 完全不同，后端会认为是 “两个不同的文件”，最终在 MinIO 里存储两份一模一样的内容，造成严重的存储浪费。
- UUID 最大的缺陷 —— 它只保证 “ID 唯一”，但不关心 “内容是否相同”，而文件上传场景的核心诉求之一就是「内容相同即视为同一个文件」。
2. 断点续传逻辑会失效
- 分片上传的断点续传依赖「同一个文件的所有分片能关联到同一个任务 ID」：
- 用 MD5：用户中断上传后，重新上传同一个文件时，MD5 不变，后端能通过 MD5 查到之前的上传进度（已传分片列表），只传未完成的分片；
- 用 UUID：用户重新上传时，生成的 UUID 是新的，后端会认为是 “新的上传任务”，只能从头开始传所有分片，断点续传彻底失效。
3. 额外的存储 / 检索成本
- UUID 比 MD5 长（36 位 vs 32 位），作为 Redis 键、MinIO 存储路径时：
- 占用更多内存（Redis 键越长，内存消耗越大）；
- 路径层级设计更繁琐（UUID 无规律，无法像 MD5 那样拆分为
xx/xx/xxxx目录结构分散文件，易造成单目录文件过多）； - 不利于人工排查（MD5 可通过文件内容反查，UUID 纯随机，无法关联到文件内容）。
四、Spring注解驱动的IoC容器机制
Spring 启动时会扫描特定注解，把标注的类 / 方法生成的对象 “收编” 到自己的容器里，后续我们需要用时直接拿，不用自己 new。
| 注解 | 作用 |
|---|---|
@Configuration | 告诉 Spring：这是一个配置类，里面会定义需要被 Spring 管理的对象（Bean） |
@Value | 从配置文件（application.yml/properties）里读取配置值，赋值给当前字段 |
@Bean | 告诉 Spring：执行这个方法，把方法返回的对象 “注册” 到 Spring 容器中 |
1、Spring自动管理这个类的完整流程
步骤 1：扫描注解（找到你的 MinioConfig）
Spring 启动后，会先执行 “包扫描”（默认扫描启动类所在包及其子包），当扫描到MinioConfig上的@Configuration注解时，会标记：
这个类是配置类，我要重点处理它里面的内容。
步骤 2：初始化 MinioConfig 类对象
Spring 会先创建MinioConfig这个类的实例（相当于你自己写new MinioConfig()），然后：
- 读取
application.yml里的minio.endpointminio.accessKey等配置； - 通过
@Value注解，把这些配置值赋值给类里的endpointaccessKey等字段。
步骤 3：执行 @Bean 方法，注册对象到容器
Spring 会遍历MinioConfig里所有带@Bean的方法，逐个执行：
- 执行
minioClient()方法：- 调用
MinioClient.builder()构建客户端对象； - 把这个
MinioClient对象 “存” 到 Spring 容器中，默认以方法名（minioClient）作为这个对象的 “标识”；
- 调用
- 执行
minioPublicUrl()方法：- 把
publicUrl的值返回，同样存到 Spring 容器中，标识是minioPublicUrl。
- 把
步骤 4：后续使用（自动注入）
当你在 Service 里写：
@Service public class MinioService { // 从 Spring 容器中取出标识为 minioClient 的对象 @Autowired private MinioClient minioClient; // 取出标识为 minioPublicUrl 的字符串 @Autowired private String minioPublicUrl; }Spring 会自动把容器里的MinioClient和String对象赋值给这两个字段，我们不用自己 new，这就是 “自动管理” 的核心体现。