★ FEATURED ARTICLE 概述交友项目里要存三类文件用户头像、动态配图、小视频。文件放哪、怎么放直接决定后面能不能横向扩容、流量账单有多大。这篇把本地磁盘、NFS、自建分布式文件系统、云对象存储四种方案摆开对比给出选型表和通用设计要点。纲要要解决的问题三类文件头像/动态配图/小视频往哪存四种存储方案服务器本地磁盘能用但多实例直接失效静态资源服务器 / NFS 共享自建分布式文件系统FastDFS / MinIO云对象存储阿里云 OSS / 腾讯云 COS / AWS S3选型决策表八个维度横向对比项目为什么两种都用图片走 OSS视频走 FastDFS通用设计要点存储与业务解耦、访问方式、私有读写、命名策略、上传校验、图片处理成本与安全流量费、防盗链、权限最小化、生命周期常见误解澄清工程里的落地形态mf-autoconfig中的 OSS 相关类要解决什么问题用户注册完要传头像发动态要配图发小视频要传视频文件。这三类文件都不适合塞进数据库——但放在哪是小团队最容易拍脑袋决定、后面又最难回头改的一件事。先看文件本身的特征文件类型体积访问频率敏感度存储诉求用户头像几十 KB ~ 几百 KB极高几乎每次列表渲染公开低延迟、CDN 加速动态配图几百 KB ~ 几 MB高公开低延迟、CDN 加速小视频几 MB ~ 几十 MB中公开大文件、成本可控体积、频率、敏感度三者的组合不同最优解就不同。下面四种方案按从最土到最省心的顺序过一遍。服务器本地磁盘最直观的做法MultipartFile收到文件transferTo写到当前机器的一个目录数据库记个路径。写个FileController半天就能跑通。上传写本地目录读取读本地目录本地无此文件客户端应用实例 A本地磁盘 /data/upload客户端应用实例 B读取失败 404问题出在部署形态上而不是代码本身多实例读不到微服务拆开后 app-server 至少两个实例请求打到 A 实例上传、再打到 B 实例读取B 的本地磁盘上根本没这个文件直接 404。负载均衡越均衡这个 bug 越随机。容器化后文件会丢容器重建、滚动发布、被调度到别的节点本地目录没挂 volume 的话随之消失。K8s 里 Pod 重启一下昨天传的头像就没了。扩容要同步数据加一台机器得把存量文件拷过去还要考虑拷贝期间新文件的落盘位置。备份麻烦每台机器都要单独备份恢复时还得对齐时间点。单机容量与带宽有上限一台机器磁盘 500G超了就没法传出口带宽也是单机的并发一上来就顶住。所以本地磁盘不是错它只适合单体应用或本地开发验证。课程里用 SpringMVC 文件上传演示的就是这个形态跑通流程可以上生产不行。静态资源服务器 / NFS 共享看到多实例读不到第一反应是搞个共享目录一台机器开 NFS其他机器把/data/upload挂载上来或者干脆单独搞一台静态资源服务器应用把文件通过 HTTP 推过去。这解决了多实例读取一致的问题——A 上传B 挂的是同一个目录也能读到。但坑换了个地方共享存储成了新的单点。NFS 那台机器挂了所有实例的读写全连带失效它同时也是性能瓶颈所有实例的 IO 都压在一个出口上。运维成本不低。挂载参数、权限映射uid/gid、断连后客户端卡死、nfs的hard/soft挂载策略选错会让应用线程直接挂住——这些都得有人盯。云环境下不划算。要在云上实现同等的共享存储往往得买 NAS 产品价格比对象存储贵还得按容量预付费弹性也差。一句话NFS 是机房时代的解法能解决问题但在云原生环境里性价比不高。自建分布式文件系统FastDFS / MinIO再往上就是自建一套分布式文件系统。以 FastDFS 为例它由 Tracker 和 Storage 组成客户端问 Tracker 要一个 Storage 地址再直连 Storage 上传。1 询问可用 Storage2 返回地址3 直传3 直传客户端/应用Tracker 集群Storage 组 A 主机Storage 组 B 主机组 A 备机 同步组 B 备机 同步它的好处很实在能横向扩展加组就能扩容量、支持大文件和断点续传、主机挂了有备机单点故障被拆掉了。讲义里对这个方案的评价是容易实现扩容但开发复杂度稍大。代价全在运维侧得自己部署 Tracker / Storage 集群配置文件和启动脚本都要调扩容、监控、备份、故障处理、磁盘满了怎么加盘——都是自己的活需要专人或团队维护对小团队是实打实的人力成本。课程里项目项目用小视频场景来演示 FastDFS见《小视频方案》一章的 FastDFS 系列。选它的理由视频文件大、数量相对可控、流量峰值不像图片那么猛自建能把边际成本压下来也不至于为了视频去扛按量计费的流量账单。云对象存储OSS / COS / S3对象存储是云厂商把存储 分发 容灾打包成服务的产物。阿里云 OSS 的定位是海量、安全、低成本、高可靠的云存储服务适合存放任意类型文件容量和处理能力弹性扩展。上传时把Bucket想成一个水桶——Bucket 是桶Object 是水文件Object 的完整路径里不含 Bucket 名。能力上是四层叠加免运维没有机器要部署没有集群要调容量自动弹性单 Bucket 没有容量上限的焦虑。自带分发与容灾可配 CDN 加速图片就近取跨区域复制做容灾备份。SDK 成熟Java 侧OSSClientBuilder建个 clientputObject就完事几行代码。权限体系完善Bucket 可设私有/公共读RAM 子账号可授权到目录级还能签临时 URL。代价有两块都是钱和锁按量付费流量是主要成本。讲义里说得很直白OSS 的上行流量免费下行流量要买。图片量一大下行流量费会很有存在感得算清楚。厂商绑定。SDK、权限模型、URL 形态都带厂商味道将来想迁到别家代码和数据迁移都有成本。课程里图片头像、动态配图走 OSS。理由是图片小、访问频繁CDN 的加速收益远大于存储本身的费用而且免运维这点对教学和中小项目都省心。选型决策表维度本地磁盘NFS / 静态资源服务器自建分布式FastDFS/MinIO云对象存储OSS/S3多实例可用性差B 实例读不到中共享目录一致好好运维成本极低但风险转移中高需盯挂载与单点高需专职维护集群极低免运维扩容能力差受单机磁盘限制中受共享存储限制好加组即扩容好弹性无限成本模型硬件一次性硬件 人力硬件 人力按量付费下行流量是大头CDN 加速需自建需自建需自行对接原生支持数据可靠性低单盘即单点中高多副本/多组高多副本 跨区适合文件类型单体小应用临时文件内网共享资源大文件、规模化自建小文件、频繁访问适合团队规模个人 / 单机 demo有自有机房的中型团队有存储运维能力的团队绝大多数团队看表能看出规律运维成本从左上到右下单调下降扩展性和可靠性单调上升。选型就是在省人力和省钱之间找平衡点。项目为什么两种都用一个项目里同时出现 OSS 和 FastDFS不是选型摇摆而是按文件特征分流文件类型存储方案理由用户头像阿里云 OSS体积小、访问极频繁、公开可读CDN 加速收益最大免运维动态配图阿里云 OSS同上且与头像共用一套 SDK 和权限体系小视频自建 FastDFS体积大、峰值流量集中按量计费账单不可控自建成本更可控判断逻辑可以固化成一个决策流程单机多实例小文件 频繁访问大文件 流量集中有没有要存的文件单机应用还是多实例?本地磁盘即可文件体积大不大?云对象存储 CDN团队有存储运维能力?自建 FastDFS/MinIO文件存储的通用设计要点方案可以换下面这几条跨方案都成立是比选哪个更重要的东西。存储与业务解耦数据库只存 URL这条是铁律数据库里存的是文件的 URL 或对象 key如2026/09/30/0f8c2a3e.jpg不是文件内容本身。把图片存成 BLOB 塞进 MySQL 会带来一连串问题——单表体积暴涨、备份文件越来越臃肿、select *拖出几百 MB 网络包、查询缓存基本失效。文件归存储系统业务库只记它在哪。好处不止省空间将来换存储方案业务表里的字段形态不变都是路径迁移只需要搬文件 改 URL 前缀。访问方式直连还是应用代理方式做法优点缺点直连存储客户端拿 URL 直接访问 OSS/CDN性能好不占应用带宽要处理鉴权、跨域 CORS、防盗链应用代理转发客户端请求应用应用再去取鉴权统一可控可做水印/裁剪应用承担流量和转发负载成为瓶颈小文件、公开资源用直连 CDN私有或需要动态处理的签名、水印走代理。私有读 vs 公共读以及签名 URLBucket 有两种基本读写模式公共读任何人拿到 URL 就能看。头像、动态配图这类公开资源适合。私有默认拒绝匿名访问必须带签名才能读。私密照片、证件类文件必须走这条。私有读的核心是签名 URL应用用私钥对对象 key 过期时间签名生成一个带Signature和Expires的临时地址比如有效期 60 秒。用户在有效期内能访问过期后链接自动失效。这样既不用把资源暴露成公共读也不用应用亲自转发流量——客户端仍然直连存储鉴权由签名机制承担。对象存储(私有Bucket)应用服务客户端对象存储(私有Bucket)应用服务客户端请求文件访问凭证生成签名 URL(有效期 60s)临时地址返回签名 URL带签名直接访问命中则返回文件命名策略别用原文件名直接把MultipartFile.getOriginalFilename()当对象名会踩三个坑中文名和特殊字符我的头像 (1).jpg上传后 URL 需要编码某些 CDN 或浏览器处理不一致。重复覆盖两个用户都传avatar.jpg后传的盖掉前传的A 的头像变成 B 的。无法分片管理所有文件挤在一个目录下运维和生命周期策略都难下手。正确做法是日期分层 UUID 保留扩展名packagecom.mf.common.util;importjava.text.SimpleDateFormat;importjava.util.Date;importjava.util.UUID;publicfinalclassFileNameUtil{privateFileNameUtil(){}/** * 生成存储对象名日期分层 UUID 原扩展名 * 例2026/09/30/0f8c2a3e-1c2b-4d5e-8f00-9a1b2c3d4e5f.jpg */publicstaticStringbuildObjectName(StringoriginalFilename){StringdatePathnewSimpleDateFormat(yyyy/MM/dd).format(newDate());Stringext;intdotoriginalFilename.lastIndexOf(.);if(dot0){extoriginalFilename.substring(dot).toLowerCase();}returndatePath/UUID.randomUUID()ext;}}日期分层还有个隐藏好处将来做冷数据转低频存储或按天清理直接针对某个前缀批量操作不用扫全量。上传校验大小与类型双查大小限制Spring 的spring.servlet.multipart.max-file-size与 Nginx 的client_max_body_size都要设只设一边会被另一个拦掉超限时返回明确的错误码别让用户看 500。类型白名单不能只看扩展名。把evil.jsp改名成evil.jpg扩名就骗过去了。要读文件的 MIME——image/jpeg、image/png才放行视频同理条件允许时再校验文件头魔数JPEG 的FF D8 FF更稳。上传目录与可执行目录必须隔离避免传上去一个可执行文件再被访问这类事故。图片处理上传原图按需生成缩略图列表页要的是小图详情页要的是大图。两种做法上传时就生成多份原图 缩略图列表读缩略图。实现简单但存储翻倍尺寸规格写死不好改。上传只存原图访问时按参数实时处理。OSS 支持在 URL 上带图片处理参数?x-oss-processimage/resize,w_200CDN 会缓存处理结果既不占额外存储规格也能随时改。推荐这条路。成本与安全的现实考虑流量费是云存储的主要成本。存储本身按 GB 计费通常不贵真正掏钱的是下行流量。给个量级认知当图片月访问量到百万级、单图几百 KB 时流量费会明显超过存储费。具体单价各单位不同以官方定价页为准不要写死数字预算阶段按访问量 × 平均文件大小 × 单价估算。防盗链。别人把你的图片 URL 直接嵌到自己网站流量全算你头上。用Referer白名单限制来源域名CDN 侧也能配。公共读的 Bucket 尤其要配。权限最小化。应用配置的 AccessKey 只授予上传到指定目录的权限别用主账号 AccessKey 全权。讲义里那句提醒值得抄下来主账号 AccessKey 拥有所有 API 权限风险很高应创建 RAM 子账号。理想形态是应用只拿临时 STS Token。备份与生命周期。历史头像、老动态的访问率会随时间下降配生命周期规则自动把冷数据转到低频/归档存储成本能降一个量级关键数据再配跨区域复制做容灾。工程里的落地形态以上方案在项目工程里落在mf-autoconfig模块——把 OSS 封装成可自动装配的组件业务模块只依赖接口不直接依赖云 SDK。mf-test ├── mf-app-server # 应用服务业务调用上传接口 ├── mf-autoconfig # 自动装配模块 │ └── src/main │ ├── java/com/mf/autoconfig │ │ ├── mfAutoConfiguration.java │ │ ├── properties │ │ │ ├── OssProperties.java # 前缀 mf.oss │ │ │ ├── SmsProperties.java │ │ │ └── AipFaceProperties.java │ │ └── template │ │ ├── OssTemplate.java # 上传封装 │ │ ├── SmsTemplate.java │ │ └── AipFaceTemplate.java │ └── resources/META-INF/spring.factories ├── mf-commons ├── mf-dubbo └── mf-modelOssProperties用ConfigurationProperties(prefix mf.oss)绑定配置字段就是连接所需的那几项mf:oss:access-key:LTAI5t****************secret:****************bucket-name:mf-125****endpoint:https://oss-cn-hangzhou.aliyuncs.comurl:https://mf-125****.oss-cn-hangzhou.aliyuncs.comOssTemplate.upload(filename, is)内部做的事正好印证前面的命名策略——yyyy/MM/dd日期目录拼 UUID 再拼原扩展名然后putObject。至于这个组件怎么一步步抽出来是后面《阿里云 oss抽取自动装配组件》要讲的内容这里不展开。常见误解澄清“本地磁盘够用”单机 demo 够用多实例部署当天就失效。要求上传后立刻能读到的场景本地磁盘第一个出局。“云存储一定更贵”只比单价确实贵但省掉的运维人力、自建集群的硬件、CDN 的加速收益要一起算。中小团队自建的那点省下的存储费往往抵不上一个运维的人力成本。“数据库可以存文件”技术上能存 BLOB工程上不该存。库体积失控、备份变慢、查询拖包得不偿失。“自建一定省钱”省的是账单花的是人力。没有持续维护存储集群的团队别碰自建。“文件 URL 直接暴露没风险”公共读的 URL 谁拿到都能用还容易被外站盗链。要么配防盗链要么私有读 签名 URL。官方文档阿里云对象存储 OSSOSS 产品定价下行流量按量计费FastDFS 项目地址MinIO 官方文档总结项目面对的是图片走 OSS、视频走 FastDFS的双方案局面。这个选择不是摇摆是按体积、访问频率、流量特征给文件分流小而频繁的交给云对象存储换免运维和 CDN大而集中的自建集群控成本。不管选哪种几条底线不变——数据库只存路径不存文件、私有资源用签名 URL、对象名用日期分层加 UUID、类型校验看 MIME 而不是扩展名。下一篇进入 OSS 的具体形态从对象存储的概念和 Bucket 讲起。
阅读完成 · 觉得有帮助？
