负载均衡后静态文件 404 的不一致

用户反馈图片时有时无，刷新一次好了，再刷新又 404。这套站要是挂在负载均衡后面、后端不止一台，基本可以断定：几台机器上的静态文件不一致，请求落到有新文件的机器正常，落到旧的那台就 404。 先确认确实是不一致 从公网循环请求同一个文件，看返回码： for i in $(seq 1 20); do curl -s -o /dev/null -w "%{http_code}\n" https://你的域名/static/logo.png; done 输出里 200 和 404 交替出现，就是典型的后端不一致。再分别 curl 每台后端的内网 IP，直接比对同一文件，锁定缺文件或文件旧的那台。 为什么会出现不一致 最常见的原因是发布方式。几台后端各自挂本地磁盘，更新时只往其中一台传了文件，忘了另一台。上传场景更容易踩坑：用户传的图片默认写在本机磁盘，另一台机器上自然没有这份文件。会话丢失也是同一个根源——session 以文件形式存在某台机器本地，下一个请求被调度到另一台，登录状态就没了。 怎么处理 思路是让"文件只有一份"或"每次都同步到位"，二选一。 方案一，共享存储。静态文件和用户上传统一放到共享存储，几台后端挂同一个目录，NFS（网络文件系统）是最简单的挂载方式，图片量大的站点更适合对象存储加 CDN 的组合。 方案二，发布同步。坚持本地磁盘也可以，但发布脚本必须覆盖所有后端，并加校验兜底： rsync -avz --checksum ./static/ user@节点B:/www/static/ md5sum /www/static/logo.png 两边 md5 一致才算发布成功，共享存储的挂载记得写进 /etc/fstab，机器重启后自动恢复。会话建议挪到 Redis 这类集中存储，改一处配置，能少一类故障。 怎么验证修好了 发布一次，对每台后端分别 curl 同一文件的完整 URL，比对返回码和 md5；再从公网循环刷新几十次，确认不再时有时无。负载均衡若带会话保持，单次正常不代表所有路径正常，循环测过才算数。 负载均衡只解决"请求分给谁"，不解决"数据放在哪"。上负载均衡之前先把文件和会话的存放方式想清楚，能省掉一大批诡异问题。