群里突然炸了；91官网 - 关于缓存设置的说法 - 细节多到我怀疑人生…？有人说是测试，有人说是回滚
前情提要 今天群里突然炸开了锅：91官网出现了异常行为，页面内容老旧、用户看到不同版本、接口返回不一致，甚至有人报告登录后状态错乱。讨论里最热的两个猜测是——有人改了缓存配置在“测试”，也有人说是“回滚”导致旧内容回来了。把这些碎片整理成一篇，方便团队内部快速理解原因、排查思路和下一步动作。
先把缓存的基本概念拉直
- 浏览器缓存（Cache-Control、Expires、ETag、Last-Modified）：靠请求/响应头控制客户端是否复用资源。
- 反向代理/CDN 缓存（Varnish、Nginx proxy_cache、Cloudflare、Akamai 等）：在边缘或中间层缓存静态与动态内容，减少后端负载。
- 应用层缓存（Redis、Memcached）：存储业务数据或渲染结果，影响 API/页面逻辑。
- 缓存键（URL、查询参数、请求头、Cookie）：决定同一个缓存是否命中不同请求。
- 缓存失效（TTL、purge、invalidation、cache-busting）：让旧缓存不再被使用或主动清除。
“测试”还是“回滚”？怎么快速分辨
- 如果是“测试”：
- 通常伴随有人主动修改配置（备注或 PR/merge）并推送到线上，可能是短期 TTL 修改、开启 stale-while-revalidate、或者改了 cache-key 设置。
- 改动窗口可能很短，有人会在群里提前说要做 A/B 或 Canary。
- 部分节点/用户受影响（canary 的典型表现），而不是全局一致。
- 如果是“回滚”：
- 常见表现是网站恢复到某个已知的旧版本状态，旧数据或旧静态资源大面积可见。
- 回滚通常伴随部署系统的记录（deploy history），会有明确的回滚操作日志。
- 可能是因为新版本有问题，团队为了快速恢复服务选择回退，或是 CI/CD 自动回滚策略触发。
可能的根因（把常见案子列清楚）
- 错误的 Cache-Control/Expires/ETag 策略：把动态页面也标记为可长期缓存，结果用户看到陈旧内容。
- CDN 或代理层的 cache-key 配置错误：cookie、授权 header、查询参数未纳入 key，导致带用户差异的内容被公用。
- 缓存穿透或错用缓存：登录态、个性化页面被缓存并复用到其他用户。
- 无效/延迟的缓存失效：发布新资源但没有 purge，或者 purge 请求失败。
- 回滚部署覆盖了新代码但没有同步更新缓存策略或静态资源版本号。
- 配置不同步：多节点/多地域配置不一致，导致不同节点行为不同。
- 应用层缓存（Redis）数据篡改或被恢复到旧快照。
- 自动化脚本或测试误触线上配置（测试脚本没有隔离权限）。
- 并发发布/回滚导致 race condition，缓存先被填充再被回滚，出现混合版本。
诊断清单（实际可执行的步骤）
- 日志与部署记录
- 看部署历史：谁在什么时候 deploy/rollback？CI/CD 的日志和时间戳。
- 查变更记录（Git commit/PR、运维工单、变更审批）。
- HTTP 响应检查
- 使用 curl -I 或 curl -v 检查响应头：Cache-Control、Age、X-Cache、Via、Server、ETag、Last-Modified。
- 关注 X-Cache / X-Edge-Result 是否显示 HIT/MISS/HIT from stale 等。
- CDN/代理控制台
- 查询最近的 purge 请求和错误日志，查看缓存命中率、流量突变。
- 检查是否有配置发布或规则变更（transform、header stripping）。
- 对比不同地域/节点
- 在不同地点/不同 ISP 下取样，确认是全网问题还是个别节点。
- 应用与缓存键
- 确认缓存键规则（是否包含 Authorization/Cookie/Query），是否误把个性化数据放进公用缓存。
- 数据层与 Redis
- 检查 Redis/Memcached 的操作日志、最近的快照/restore 记录、key TTL 是否被批量修改。
- 回滚证据
- 查找回滚命令执行记录、K8s rollout history、旧版本容器镜像被重新部署的证据。
- 瞬态操作
- 查 audit log，看是否有运维或自动化脚本短时间内更改多个环境配置。
即时应急措施（优先级排序）
- 先保证用户体验（短期补救）
- 对高度敏感页面设为 no-cache 或短 TTL，临时绕过边缘缓存直接到源站（在流量允许范围内）。
- 对登录/支付等敏感端点添加 Cache-Control: private/no-store，防止缓存个人数据。
- 如果怀疑旧缓存泛滥，触发针对性 purge（按路径、前缀或 cache-key）或批量 invalidation。
- 如果回滚导致问题，评估是否继续回滚或重部署修复版本；如果回滚必须回退，先清缓存再回退可避免旧资源立刻生效。
- 快速定位与恢复
- 打开或生成临时诊断页面，汇总当前缓存命中率、最近 purge 条目、当前 active release 版本，发到群里写明时间线，避免重复操作。
- 限制无关人员操作，指定一名“操盘手”统一执行清理/回滚指令，减少并发改动风险。
长期改进建议（防止下次炸锅）
- 把缓存策略写入代码库并走审查流程，配置与业务代码同源管理（Infrastructure as Code）。
- 对个性化内容单独分流缓存或使用 cache key 包含用户标识（但注意隐私）。
- 上线前做灰度/Canary 发布并把缓存变更纳入灰度计划，先在小流量节点验证缓存规则。
- 自动化 purge 与版本化静态资源（hash 文件名），避免依赖手动失效。
- 引入观测与告警：缓存命中率、错误率、Age 分布异动都要告警。
- 建立回滚与回退的 runbook：谁触发、如何验证、回退后如何同步缓存。
- 把敏感缓存配置（能影响生产的命令）限制权限并添加审批链与审计日志。
- 定期做灾备演练和缓存失效演练（包含 CDN purge 效果验证）。
如何在群里沟通（减少恐慌、提高效率）
- 统一口径：汇报已知事实（时间、影响范围、临时措施），避免传播未经确认的猜测。
- 指定联络人：一个人在群里负责更新进展和下一步动作，其他人暂停独立操作以免冲突。
- 关键信息格式化：时间点、操作人、命令、结果（成功/失败）、下一步计划。
- 记录并归档：把最终排查结论写进变更/事故记录，变成团队知识资产。
结语（给技术同事的一点现实话） 缓存既是性能的利器，也是最会在不经意间“给你上演惊喜”的东西。一句配置改错、一次忘记 purge、或一次回滚都可能把线上用户的页面变成“时间胶囊”。技术上把流程和观测连通起来，组织上把权限和沟通理顺，日常把缓存当作“有状态的关键依赖”来管理，能把这种群炸事件的频率和影响降得很低。今天的细节混乱可以当成一次很值钱的教训：查清来龙去脉、补上缺失的流程、把整个事件写成 incident report，下次群里就少些猜测，多些解决方案。