LobeChat缓存穿透预防方案

LobeChat 缓存穿透预防方案

在构建现代 AI 聊天应用时，性能与安全的平衡往往比我们想象中更脆弱。一个看似简单的“获取会话”请求，若被恶意利用，可能在几分钟内拖垮整个后端服务——这正是缓存穿透的真实威胁。

LobeChat 作为基于 Next.js 的开源大模型交互框架，支持多模型接入、插件系统和语音对话等功能，广泛用于个人助手、智能客服等场景。随着其部署范围扩大，尤其是面向公网开放的服务实例，如何防止攻击者通过构造大量不存在的会话 ID 来持续冲击数据库或模型接口，已成为不可忽视的工程挑战。

这类问题的核心在于：传统缓存只保存“存在的数据”，而对“根本不存在”的查询不做任何记录。于是每一次非法请求都会穿透缓存，直达后端。当并发量上升时，数据库连接池迅速耗尽，响应延迟飙升，最终导致服务不可用。

要真正解决这个问题，不能仅靠“加机器”或“升配置”，而是需要从架构层面设计一套多层次、高效率的防护机制。本文将结合 LobeChat 的实际运行环境，深入探讨一种融合空值缓存、布隆过滤器与原子操作的综合防御策略，并给出可落地的技术实现。

缓存的本质是“用空间换时间”。在 LobeChat 中，常见的缓存对象包括用户会话上下文、角色预设配置、插件元信息等。这些数据访问频率高、更新频率低，非常适合放入内存缓存（如 Redis）中加速读取。

典型的缓存流程非常直观：

请求到达 → 检查缓存 → 命中？→ 返回结果 ↓ 否 查询数据库/远程API ↓ 写入缓存（设置TTL） ↓ 返回结果

但这个流程有个致命漏洞：如果查询的是一个根本不存在的资源（比如session:user123:invalid456），数据库返回null，缓存层通常不会存储这个结果。下一次同样的请求进来，又得重复一遍完整流程。

设想有攻击者编写脚本，循环发送随机生成的会话 ID，每秒几千次。由于每个 ID 都是无效的，缓存永远不命中，所有请求都落到数据库上。即使你的数据库能扛住单次查询压力，这种持续不断的“毛刺流量”也会迅速耗尽连接数，甚至波及到模型推理服务本身。

这就是缓存穿透的典型表现。它不像缓存雪崩那样由大规模失效引发，也不像缓存击穿那样集中在热点 key 上，它的隐蔽性更强——每一个请求看起来都合法，却共同构成了系统级风险。

那么，该如何应对？

最直接的想法是在数据库返回null时，仍然往缓存里写一条“空值标记”，比如一个空字符串或特殊占位符，并设置较短的过期时间（TTL）。这样后续相同的非法请求就会命中缓存，直接返回失败，不再打扰后端。

async function getCachedSession(userId: string, sessionId: string) { const key = `session:${userId}:${sessionId}`; const cached = await redis.get(key); if (cached !== null) { return cached === '' ? null : JSON.parse(cached); } const session = await db.getSession(userId, sessionId); if (!session) { // 关键步骤：写入空值缓存，防止重复穿透 await redis.setex(key, 60, ''); // 仅保留60秒 return null; } await redis.setex(key, 3600, JSON.stringify(session)); return session; }

这一招确实有效，但在高并发环境下仍存在隐患：多个请求几乎同时到达，发现缓存未命中，于是同时去查数据库，最后也都同时写入空值。虽然结果正确，但造成了不必要的数据库访问放大。

为了解决这个问题，我们需要让“判断是否存在 + 写入空值”这两个动作具备原子性。Redis 提供了 Lua 脚本支持，可以在服务端一次性执行多条命令，避免竞态条件。

const SET_IF_MISS_LUA = ` local key = KEYS[1] local ttl = ARGV[1] if redis.call("EXISTS", key) == 0 then redis.call("SETEX", key, ttl, "") return 1 else return 0 end `; async function protectCachePenetration(redis: Redis, key: string, ttl: number) { const result = await redis.eval(SET_IF_MISS_LUA, 1, key, ttl); return result === 1; }

这段 Lua 脚本确保只有第一个请求能够成功设置空值，其余请求会在EXISTS判断阶段就被拦截。这是保障高并发下缓存一致性的关键手段。

不过，如果我们等到请求进入业务逻辑才开始处理，其实已经晚了一步。有没有办法在更早阶段就把非法请求拒之门外？

这就引出了另一个利器：布隆过滤器（Bloom Filter）。

布隆过滤器是一种概率型数据结构，用于快速判断某个元素是否“可能存在于集合中”。它有两个特点：
- 允许少量误判（把不存在的判定为存在）；
- 绝不允许漏判（存在的一定判定为存在）。

在 LobeChat 场景中，我们可以维护一个包含所有合法会话 ID 的布隆过滤器。当新请求到来时，先通过过滤器做一次筛查：

function isSessionExists(sessionId: string): boolean { return bloomFilter.test(sessionId); // 可能误判，但不会漏判 } async function safeGetSession(sessionId: string) { if (!isSessionExists(sessionId)) { console.warn(`Blocked potential cache penetration: ${sessionId}`); return null; } return getCachedSession(sessionId); }

虽然极少数情况下真实会话可能被误判为非法（可通过白名单补偿），但绝大多数无效请求在这里就被拦截了，根本不会进入缓存查询流程。这对于减轻系统负载极为重要。

当然，布隆过滤器本身也需要维护。建议在服务启动时加载全量有效 ID，并在运行时动态插入新创建的会话。对于大规模部署，可以考虑使用 Redis 官方模块RedisBloom，获得更好的性能与管理能力。

结合以上技术，我们在 LobeChat 中可以构建一条完整的防护链路：

1. 请求首先经过 Nginx 或 API 网关，进行 JWT 鉴权和速率限制；
2. 进入业务层后，使用布隆过滤器快速筛除明显非法的 ID；
3. 查询 Redis 缓存：
   - 若命中且非空，直接返回；
   - 若命中为空字符串，返回 404；
   - 若未命中，则尝试从数据库加载；
4. 数据库无结果时，调用 Lua 脚本原子化设置空值缓存（TTL=60s）；
5. 正常数据则写入缓存（TTL=1~24h，视更新频率而定）。

这套“三层防御”体系显著提升了系统的抗压能力：

在实际部署中还需注意几个关键细节：

• TTL 设置要有区分度：空值缓存不宜过长（推荐 30~300 秒），以免影响后续合法的新建操作；正常数据可根据业务特性设置 1 小时到 1 天不等。
• 监控必须到位：关注“空值缓存命中率”，若突然升高，可能是遭遇扫描攻击；同时监控 Redis 内存使用情况，防止因缓存膨胀导致 OOM。
• 降级机制不可少：当 Redis 不可用时，应启用本地内存缓存（如 Node.js 的Map或LRUCache）作为应急缓冲，避免全线崩溃。
• 动态资源要及时同步：新创建的会话、角色或插件，除了写入数据库，也应立即加入布隆过滤器，否则会导致短暂的“误判窗口”。

此外，安全性方面也不能放松。即使是内部团队使用的 LobeChat 实例，也应启用 JWT 鉴权，限制未登录用户的访问范围。在 Nginx 层配置limit_req_zone，控制单个 IP 的请求频率，进一步压缩攻击面。

值得一提的是，该方案的价值不仅限于会话管理。LobeChat 中的“角色预设”、“插件配置”、“知识库索引”等静态资源同样适用此类保护策略。通过统一的缓存治理规范，可以系统性地提升整体服务稳定性。

最终你会发现，真正的系统可靠性，往往不取决于用了多少高端技术，而在于是否在每一个细节上都做了充分的边界假设。缓存不只是性能优化工具，更是系统弹性的重要组成部分。

在 AI 应用日益普及的今天，前端不再是简单的界面展示层，而是承载着复杂状态管理和高并发交互的核心组件。LobeChat 的这类实践表明，即使是开源项目，也能通过严谨的设计实现企业级的健壮性。

那种“只要模型回答得好就行”的时代已经过去。用户体验的背后，是一整套看不见的基础设施在默默支撑。而提前预防缓存穿透，就是其中至关重要的一环。