图片迁移对象存储的收益与步骤

图片是网站里最占带宽和磁盘的资源，把它们迁到对象存储往往是最见效的一步优化：应用服务器只留代码和数据库，图片的流量压力由存储侧分担。 一、迁移前盘点 先摸清家底： du -sh /var/www/uploads/ find /var/www/uploads -type f | wc -l 记下总大小和文件总数，迁移完成后要用来校验。图片按上传日期分目录的，就按目录划批，一次搬一段，出问题影响面也小。盘点时顺带看哪类图片最多：截图、相册图、图标的处理策略各不相同，图标这类小文件其实可以留在本地，不值得一起搬。 二、增量双写与存量搬运 改动最小的方案是先双写：应用上传图片时同时写本地和对象存储，保证迁移期间的新文件两边都有。上传代码里加失败重试和日志，本地成功、存储失败是最需要盯的情况。存量部分用对象存储 CLI 的同步类子命令按目录分批上传，比如先传 2023 年的目录、再传 2024 年的，每批完成后比对文件数： find /var/www/uploads/2024 -type f | wc -l 两边数字一致再进下一批。分批的好处是中断后只需重跑当前目录，不用整个重来。 三、URL 替换与 301 数据库富文本里存着旧图片地址的，先备份再替换： mysqldump 数据库名 > backup.sql UPDATE posts SET content = REPLACE(content, 'http://example.com/uploads/', 'https://新地址/'); 替换语句执行后抽几条记录核对，REPLACE 是全量匹配，旧地址写得太短会误伤其他内容。已经散布到站外的链接收不回来，本地保留一份旧路径映射，在 nginx 里对 /uploads/ 返回 301 跳转到对象存储地址，老链接自动跟过去，站外引用不会碎图。 四、收尾与观察 双写稳定运行一两周、日志里没有上传失败记录后，再停掉本地写入。删除本地历史图片之前留一份冷备份，对象存储误删时还有退路；存储侧再把防盗链和访问日志配好，图片流量才真正可控。整条链路里最值得花时间的是第三步，URL 改不干净，用户看到的就是一排加载失败的占位框。