49图库镜像同步落地：发布到全部节点生效 90 秒

2026 年 6 月 12 日，49图库完成源站与边缘节点的镜像同步改造。发布流程固定为构建、校验、同步、刷新四步，静态页面到全部节点生效约 90 秒。每次发布保留上一版本，回滚只需执行一条命令，6 月共执行 4 次回滚，均在 3 分钟内完成。

改造前，发布是一次手工操作：本地构建、上传文件、逐个节点刷新缓存。问题出在第三步和第四步之间——文件上传完了，缓存还没刷，访问者可能拿到新 HTML 配旧样式，页面布局直接错位。6 月初的一次发布就出现了这种情况，持续约四分钟。

新流程把“新旧混杂”当成首要敌人。构建产物带版本号，同步过程先写临时目录再原子切换，缓存刷新按页面清单逐个提交，全部成功才标记发布完成。任何一步失败都自动停在上一版本，不出现半成品状态。

发布四步各做什么

构建：从同一份数据生成全部静态页面与 sitemap，输出到带版本号的目录，例如 v20260612。校验：检查内部链接是否全部存在、sitemap 与页面清单是否一致、结构化数据字段是否完整，任一项失败即中止。

同步：把版本目录整体上传到源站，再触发节点拉取，节点侧先下载到临时目录并校验文件数，确认后再切换软链接。刷新：按页面清单提交缓存刷新，顺序为样式与脚本在前、页面在后，避免访问者拿到新页面配旧样式。

节点按地域分布，访问时由调度就近分配。源站只保存当前版本与上一版本，边缘节点保留当前版本并在拉取时校验文件数量与摘要。节点之间的内容不做互相复制，全部从源站拉取，避免出现某个节点带着一份来历不明的旧文件。

发布最怕的不是慢，是旧的和新的同时在线。慢一分钟无所谓，混四分钟就是事故。—— 49图库运维负责人 赵启明

同步耗时与失败处理

全部静态文件约 2.1 MB，压缩后 640 KB。源站上传约 8 秒，节点拉取 34 秒，缓存刷新 41 秒，加上校验与切换，从触发到全部生效的中位耗时 90 秒。页面数量增加时耗时增长主要来自刷新，每篇资讯约增加 0.4 秒。

6 月共发布 21 次，其中 17 次一次成功，4 次因校验失败中止。失败原因分别是：两处内部链接指向已删除的旧页面、sitemap 少了 1 篇资讯、结构化数据缺图片宽高、导出文件字段与字典不一致。四类问题都在构建阶段可查，未影响线上。

静态资源统一带版本号参数，样式与脚本为 ?v=1，图片按内容摘要命名。版本号变化时缓存键随之变化，旧缓存自然失效，不需要逐个节点清理。HTML 使用短缓存并在响应头标注构建时间，确保新页面在刷新后立即可见。

边缘节点的作用是缩短物理距离。源站位于一个地域，访问者分布在不同地区时，由调度把请求分配给最近的节点，静态文件命中节点缓存后不再回源。节点不保存数据库，也不执行构建，只做静态文件的读取与缓存，职责单一，出问题时也容易定位。

回滚为什么只要一条命令

节点侧用软链接指向当前版本目录，回滚就是把软链接指回上一版本再刷新缓存。上一版本目录保留 14 天，不立即删除，磁盘占用约 30 MB，相比重新上传全部文件的耗时，这点空间值得留。

6 月的 4 次回滚都发生在发布后十分钟内，原因均为样式在窄屏下出现横向滚动条。回滚后页面立即恢复，问题在测试环境修复后再发。回滚记录与发布记录写在同一份日志里，谁在什么时间改了什么，事后可查。

每次发布后有十分钟观察期，值班人员盯三项指标：页面可访问性、静态资源 404 数、首字节时间。任一指标异常即执行回滚，不等待排查结论。6 月的 4 次回滚全部在这个窗口内完成，使用者侧感知到的异常时间都没有超过 3 分钟。

版本号参数目前统一为 ?v=1，只有在样式或脚本内容变化时才递增。图片不依赖版本号，按内容摘要命名，内容不变则文件名不变，缓存可以长期保留。这条约定写在发布规范里，避免有人为了“强制刷新”而随意改版本号，导致缓存整体失效。

回滚能力决定了发布的胆量。能三分钟退回去，才敢一天发两次。—— 49图库前端负责人 何思远

发布日志按版本号记录，包含构建时间、页面数量、校验结果与回滚情况，保留 90 天。镜像同步不影响使用者访问，改造期间未出现计划外中断。下一步计划把校验项从 11 项扩展到 15 项，增加图片尺寸与字体文件缺失检查。