镜像站点的核心不是“复制一份网站”，而是同步和回源两条链路要各司其职：同步保证镜像上的数据与源站一致，回源保证用户请求到镜像后能拿到正确内容，二者取舍不同却互相牵制。很多初次搭建镜像站的人，往往只关注文件有没有传过去，忽略了回源策略，结果源站流量被镜像拖垮，或者镜像内容长期不更新,今天咱们把这两件事拆开讲清楚。
镜像站点部署同步和回源的区别是什么
同步和回源听起来都是“让镜像和源站保持一致”，但它们的职责完全不同，很多人把这两个概念混在一起,导致排查问题时走了弯路。
同步解决的是“数据对不对”
同步是指把源站的文件、数据库、配置数据复制到镜像节点，它的核心指标是一致性和时效性，静态文件可以用rsync做增量推送，动态数据要用数据库主从复制或者消息队列,纯靠手工上传的镜像站基本活不过三个月。
同步的典型场景是：你更新了一篇文章，改了图片，加了文章，源站内容发生变化，镜像节点需要感知到这个变化，并拉取最新数据，同步做得好,用户访问镜像时看到的内容和源站是同一个版本。
回源解决的是“请求去哪取数据”
回源不是复制数据，而是请求转发，当用户访问镜像节点时，镜像节点并没有完整的源站数据，或者数据已经过期，它会主动向源站发出请求,把用户需要的内容拉回来再返回给用户。
回源的典型路径是：浏览器请求镜像的图片 → 镜像节点发现自己没有缓存这张图 → 镜像节点回源站获取图片 → 源站返回图片 → 镜像节点再把图片给用户，注意，这里回源发生在请求时，而同步发生在请求前，同步负责把内容提前搬过来,回源负责在没搬过来时临时去拿。
业内专家指出，静态资源占比较高的站点，回源率通常很低，因为大部分资源能在镜像节点命中缓存；但如果镜像节点存储空间不足导致频繁淘汰文件，回源率会明显上升,源站带宽压力也随之变大。
镜像站点回源是什么意思？回源逻辑和带宽成本怎么控制
很多人第一次接触“回源”这个词时都会懵，简单说，
镜像站点回源就是镜像节点在没有所需数据时，原路返回源站拉取内容的机制，它和CDN回源本质上是一回事，只是CDN通常有中心节点做调度,而镜像站的回源路径更直接。
回源HOST是第一个要设置对的地方
比如你的源站域名是www.a.com，镜像域名是mirror.a.com，给镜像节点配置回源时，回源HOST一般要保留为源站域名，如果错误设成mirror.a.com,源站在识别虚拟主机时可能会返回404或者跳到错误页面。
很多镜像站部署后出现大量404，不是文件没同步，而是回源HOST写错了，排查命令也很简单,在镜像服务器上执行：
curl -H "Host: www.a.com" http://源站IP/robots.txt
如果返回正常内容，说明回源HOST没有生效，需要检查Nginx反代配置里的proxy_set_header Host。
控制回源带宽的几个关键开关
回源太频繁，源站扛不住，控制回源的核心是提高镜像节点的缓存命中率。
- 设置合理的
Cache-Control和Expires头部,让静态资源在镜像节点多存一段时间。 - 开启
proxy_cache并在Nginx里定义缓存路径,实测能减少一大半回源量。 - 对大文件启用Range回源，用户请求图片或视频时，镜像节点只回源需求的分段,而不是整个文件。
行业共识认为，动态站回源优先级要低于静态资源同步，因为动态内容回源再返回的延迟，比直接访问源站还高,这种场景下做镜像没有任何意义。
回源和同步的顺序决定一致性
假设你源站更新了一张图片，但文件同步还没完成，此时用户访问镜像，镜像触发回源拉到了新图片，然后同步任务又把旧图片传了上来，覆盖了回源拉取的新图片，这种“回源覆盖同步”的文件冲突,会造成非常隐蔽的内容不一致问题。
解决方案是在同步脚本里加一个时间戳判断，或者让回源拉取的文件直接写入独立缓存目录，不与同步目录交叉，如果用的是rsync，可以考虑--ignore-existing参数,避免覆盖已经存在的文件。
镜像站同步方案对比：rsync、mysql主从、对象存储分发怎么选
同步方案的选择直接决定镜像站的维护成本，没有万能方案,只有适不适合你的站点类型。
静态文件为主：rsync增量同步
绝大多数个人站点和中小型网站都用这种方案，rsync通过对比源端和镜像端的文件差异，只传输变化部分，效率很高，配合cron定时任务,基本做到分钟级同步。
常用命令示例：
rsync -avz --delete --exclude='cache/' /www/wwwroot/site/ root@镜像IP:/www/wwwroot/mirror/
参数解释：-a保留文件属性，-v输出明细，-z传输时压缩，--delete删除镜像端多余文件，让它与源站完全一致，定时任务建议每小时跑一次，如果内容更新频繁,可以缩短到每5分钟。
动态数据库：mysql主从复制
论坛、电商类站点的镜像，光同步文件不够，数据库必须实时或准实时复制，mysql主从复制工作逻辑是：源库开启binlog，从库请求binlog并重放变更,达到数据一致。
配置主从复制不需要写代码,操作路径是：
- 源库
my.cnf里设置log-bin=mysql-bin,重启mysql。 - 创建复制专用账号：
CREATE USER 'repl'@'%' IDENTIFIED BY '密码'; - 授权：
GRANT REPLICATION SLAVE ON . TO 'repl'@'%'; - 在镜像库执行
CHANGE MASTER TO指定源库binlog位置，然后START SLAVE; - 用
SHOW SLAVE STATUSG查看Seconds_Behind_Master字段判断延迟。
如果Seconds_Behind_Master一直大于300，说明网络延迟或磁盘IO跟不上,优先检查带宽和binlog大小。
大规模媒体文件：对象存储分发
文件数量超过百万级时，rsync扫描文件列表会非常慢，容易卡死在大量小文件上，这种情况更适合把文件放在对象存储，然后用存储桶复制功能自动同步，源桶和镜像桶之间通过事件通知触发复制,实时性远高于定时rsync。
镜像服务器同步慢怎么办？先看这三处瓶颈
镜像服务器同步慢的原因常见于三个环节,挨个排查基本不会错：
- 网络带宽瓶颈：用
iperf3测源站和镜像站之间的实际带宽，如果只有几Mbps,同步快不起来。 - 小文件数量过多：小文件会消耗大量CPU和磁盘IO，处理办法是先打包成tar再同步,或者改用存储桶复制。
- 磁盘写入速度低：镜像服务器是机械盘，源站是SSD，同步速度就会被镜像端拖死，建议镜像端至少使用SSD,尤其是跑数据库的机器。
镜像站同步与回源常见问题
以下问题是部署镜像站时最容易踩的坑,按实际场景列出。
镜像服务器同步慢怎么办？延迟多久算正常？
静态文件定时同步，正常情况延迟应该在请求访问前完成，用户无感知即可，如果数据库同步延迟持续超过60秒，就要考虑网络质量问题和主库负载，实际业务中，允许的延迟取决于站点类型：新闻站秒级延迟，个人博客分钟级延迟都能接受，关键不是追求绝对实时,而是保证用户访问时数据已完成同步。
镜像站回源后源站流量增加明显，如何限制？
先看访问日志，确认回源请求集中在哪些URL，如果是图片刷量大，给图片加更长的缓存时间，并在镜像节点开启proxy_cache_valid，如果是动态接口被大量回源，考虑在源站加访问频次限制，或直接用CDN替代镜像,因为CDN的边缘节点缓存策略更成熟。
静态文件和数据库可以同时做镜像吗？
可以，而且大多数镜像站都是混合架构，静态文件走rsync或对象存储复制，数据库走主从复制，两者独立运行，需要额外注意文件路径和数据库内容之间的关联，避免同步时间差导致图片存在但数据库里对应文章还没更出来，建议先同步数据库，再触发静态文件同步,可以大幅度减少前后端资源不同步的时间窗口。
镜像站的维护不是一劳永逸，同步和回源必须放在一起监控，没有绝对完美的方案，但理解它们各自的职责，再用缓存和同步频率把回源量压下来，镜像站就能稳定跑下去，你只需要记住一句话：同步做得好，回源自然少；回源策略稳,源站不嫌累。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/765564.html
