平滑扩容数十万小图的关键是“不卡、不丢、不重复、不干扰线上服务”：预同步限速+后台运行、inotify实时追增量、checksum校验一致性、灰度验证后再切流。
直接用 rsync -avzP 推送是基础，但数十万张图片（尤其小图居多）平滑扩容，关键不在“能不能传”，而在“不卡、不丢、不重复、不干扰线上服务”。以下是实战中真正有效的做法：
先做预同步，避开业务高峰
新节点上线前 1–2 天，就启动首次全量同步（不是上线那一刻才开始）：
- 用 带限速和后台运行 的命令，避免打满带宽或拖慢源服务器磁盘 I/O：
rsync -avz --bwlimit=5000 --delete --exclude='*.tmp' /data/images/ user@new-node:/data/images/ &
（--bwlimit=5000表示限速 5MB/s，可根据网络和磁盘负载动态调整） - 同步期间保留
--delete，确保目标结构与源严格一致；但首次同步后，后续增量可先去掉该选项，确认无误再启用 - 用
screen或nohup启动，防止终端断开中断
用 inotify 实时追增量，而非只靠定时任务
静态资源常持续上传（如用户头像、商品图），光靠 cron 每 5 分钟 rsync 会积压、延迟明显。应让新节点“跟上最后一公里”：
- 在源服务器部署 inotifywait + rsync 小脚本，监听
/data/images/下的CREATE,MOVED_TO,DELETE事件，触发对应文件的单次 rsync（非全目录） - 避免高频事件风暴：加
--monitor --timeout 30和简单队列去重（例如用find . -mmin -1批量抓取最近变更） - 注意：inotify 监控深度有限，若目录层级深、文件极多，建议按日期/哈希分片监控（如
/images/2026/07/21/），降低内核压力
校验一致性，不止看文件名和大小
图片文件易因传输中断、磁盘错误或 NFS 缓存导致内容损坏，仅靠 rsync 默认的 size+mtime 判断不够可靠：
- 上线前执行一次 基于 checksum 的最终校验：
rsync -avnc --checksum /data/images/ user@new-node:/data/images/
（-n模拟，--checksum强制比对 MD5，耗时但必要） - 对关键目录（如热门 banner、默认头像）可额外抽样
md5sum对比，或用diff -r快速扫异常子目录 - 记录校验结果日志，留痕备查
切换流量前做灰度验证
同步完成 ≠ 可立即切流。需验证新节点实际服务能力：
- 在新节点启用 Nginx，配置
location ~* \.(jpg|jpeg|png|webp)$ { add_header X-Node "new"; }，通过 HTTP Header 区分来源 - 用 CDN 或 DNS 权重，将 1% 流量导向新节点，观察 4xx/5xx 错误率、响应时间、图片加载完整性（可用 Puppeteer 抓取热门 URL 自动比对渲染结果）
- 确认无问题后，再逐步提升至 100%，同时监控源节点负载是否回落
