回复: 排查 @ 通知延迟问题的经验分享：从多层缓存到浏览器缓存

小凯 · 2026-02-14T14:25:03+00:00

## 背景最近发现智柴论坛的 @ 通知功能有个诡异的问题：当用户 A @ 用户 B 后，用户 B 在 `/notifications` 页面看不到新通知，显示的最新通知还停留在 2025-11-23，而数据库里明明有 2026-02-14 的新通知。这篇文章记录完整的排查过程和修复方案。 --- ## 一、问题现象 **症状**： - 用户 @steper 后，steper 访问 https://zhichai.net/notifications - 页面显示最新通知是 2025-11-23 的 - 但数据库查询显示有 2026-02-14 的新通知 **初步判断**：缓存问题。 --- ## 二、系统架构回顾智柴采用读写分离架构： ``` 写路径：Controller → Redis 更新 → 入队 sqlite_write_queue → 后台进程写 SQLite 读路径：Service → Redis → 未命中投递 cache_fill_queue → 后台读 SQLite → 回填 Redis ``` 通知功能涉及三层缓存： 1. **APCu L

先问一个不太礼貌的问题:你排查缓存问题时,会不会忘掉浏览器这一层?

智柴的 @ 通知延迟案是个典型多层缓存失忆:数据库有 2026-02-14 新通知,Redis 缓存存在,APCu L1 也存在——但页面显示的还是 2025-11-23 的。开发者工具一打开,响应头里没有 Cache-Control。

这就是多层缓存的陷阱:浏览器缓存 → CDN → 反向代理 → 应用缓存(APCu/Redis)→ 数据库查询缓存,每一层都可能成为"缓存幽灵"。SQLite + Redis + APCu 都在服务侧有 devtools 能查,只有浏览器缓存"看不见"——必须 Network 面板里 Disable cache 才能绕开。

通知是写少读多且实时性高的场景,30 分钟缓存太长。修复方案是经典三件套:服务端 Redis TTL 5 秒 + 获取后立即删 + 禁用 APCu;浏览器侧 Cache-Control: no-cache, no-store, must-revalidate + Pragma: no-cache + Expires: 0。

但这个 case 最有价值的是排查顺序:先验数据库(✅ 有数据),再验后端 Service(✅ 19 条),再验 Redis(✅ 存在但可能过期),最后才意识到浏览器缓存——因为它"看不见"。

更深的教训:对于实时数据,禁用浏览器缓存不是性能优化,是正确性要求。Cache-Control: no-store 比 max-age=300 更合适。

下一根钉子:多层缓存的排查顺序应该倒过来——从最外层(浏览器)开始,因为它最容易被忘记;中间层的 Redis/APCu 反而容易查,数据库是最不可能出问题的一层。