跨请求 LRU 缓存React Server 端共享数据缓存的工程实践OpenMetadata【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata导读本文以仓库中 server-cache-lru.md 这一规则文档为骨架系统讲解 React/Next.js 服务端场景下跨请求共享数据的核心缓存方案——LRU 缓存。你会掌握为什么React.cache()无法覆盖跨请求场景、如何用lru-cache实现带容量上限与 TTL 的进程内缓存、缓存键的选取与失效策略、Vercel Fluid Compute 与传统 Serverless 两种运行模型下的差异以及 LRU 缓存与仓库中其他服务端性能规则的搭配边界。该规则属于 react-best-practices 技能包Server-Side Performance服务端性能HIGH 影响等级板块是 AI 代理在审查或重构服务端代码时的高优先级检查项。规则定位服务端性能体系中的跨请求缓存在 React Best Practices 规则体系中本规则被归入Section 3 Server-Side PerformanceHIGH对应的规则文件为 server-cache-lru.mdfrontmatter 中impact: HIGH、impactDescription: caches across requests。服务端性能板块包含多条相互配合的规则理解本规则需要先看清它们的边界规则文件作用域核心目标server-cache-react.md单次请求内用React.cache()做请求级去重去重查询/鉴权server-cache-lru.md本文跨请求、进程内用 LRU 缓存共享高频只读数据server-no-shared-module-state.md进程内共享状态禁止用模块级可变变量传递请求数据server-hoist-static-io.md模块初始化将静态 I/O字体、Logo、配置提升到模块级只加载一次规则文档原文开宗明义地指出React.cache()only works within one request. For data shared across sequential requests (user clicks button A then button B), use an LRU cache.即React.cache()只在一次请求内生效对于需要在连续多次请求之间共享的数据例如用户先点击按钮 A、再点击按钮 B两个请求都需要同一份数据应当使用 LRU 缓存。这与 server-no-shared-module-state.md 中列出的安全例外正好呼应——该规则明确允许Shared caches intentionally designed for cross-request reuse and keyed correctly有意设计用于跨请求复用且正确加键的共享缓存LRU 缓存正是这种合法共享状态的标准形态。为什么React.cache()不够用请求级去重 vs 跨请求复用先明确一个前提。React 的cache()API 用于单次请求内的去重在一个请求的渲染过程中多个组件同时调用同一个缓存函数底层只执行一次查询。规则文档 server-cache-react.md 给出了典型用法import { cache } from react export const getCurrentUser cache(async () { const session await auth() if (!session?.user?.id) return null return await db.user.findUnique({ where: { id: session.user.id } }) })同一请求内多次调用getCurrentUser()只执行一次查询。但它的缓存生命周期以请求为边界请求结束后缓存即被丢弃。当用户的连续多个请求比如点击按钮 A 触发请求 1、点击按钮 B 触发请求 2都需要同一份数据如用户资料、权限位、低频变化的配置时React.cache()无法避免请求 2 再次打数据库。此时就需要一个跨请求存活、按 LRU 策略淘汰的进程内缓存。二者的分工可以概括为React.cache()解决同一个请求里重复调用的重复查询LRU 缓存解决连续多个请求读取同一份数据的重复查询以空间内存换时间数据库往返。规则文档 server-no-shared-module-state.md 同时提醒模块级共享状态用于跨请求缓存时必须确保缓存键正确绝不能把请求相关、用户相关的可变数据放进无键共享状态否则会引发并发污染与数据泄露。LRU 缓存以键 → 值组织数据天然满足正确加键的要求但键的选取仍需谨慎见下文缓存键的设计。核心实现基于lru-cache的跨请求缓存规则文档给出了可直接落地的完整实现TypeScript 示例对应 server-cache-lru.md 原文档import { LRUCache } from lru-cache const cache new LRUCachestring, any({ max: 1000, ttl: 5 * 60 * 1000 // 5 minutes }) export async function getUser(id: string) { const cached cache.get(id) if (cached) return cached const user await db.user.findUnique({ where: { id } }) cache.set(id, user) return user } // Request 1: DB query, result cached // Request 2: cache hit, no DB query这段代码展示了 LRU 缓存的完整闭环初始化缓存实例LRUCachestring, any指定键为字符串、值为任意类型设置容量上限max: 1000限制最多缓存 1000 个条目超过后自动淘汰最久未使用的条目LRU 语义设置过期时间ttl: 5 * 60 * 1000表示条目存活 5 分钟毫秒单位到期后自动失效避免缓存永远新鲜导致数据陈旧读缓存cache-aside 模式先cache.get(id)命中直接返回未命中回源未命中才执行数据库查询db.user.findUnique(...)回填缓存cache.set(id, user)将查询结果写入缓存供后续请求复用。规则文档明确其适用场景Use when sequential user actions hit multiple endpoints needing the same data within seconds.——当用户的连续操作会命中多个接口、且这些接口在几秒内需要同一份数据时使用。典型例子包括用户资料、租户/工作空间信息等跨接口高频复用的实体权限位、特性开关feature flag等低频变化的配置字典表、元数据等只读且体量可控的数据。参数解读max与ttl规则文档示例中出现的两个核心参数来自lru-cache包官方参考 的 references 中也列入了该项目max最大条目数限制缓存占用的条目数量防止内存无限增长。达到上限时lru-cache会按照最近最少使用的顺序淘汰最久未被访问的条目。实际项目中应根据单条数据的内存占用与可用堆内存来设定例如缓存单条约 1KB 的用户对象时max: 10000约占用 10MB 级别内存。ttl生存时间毫秒为条目设置绝对过期时间。过期后条目变为不可用get返回undefined下次访问会触发重新回源。ttl: 5 * 60 * 1000即 5 分钟。注意 TTL 解决的是数据新鲜度max解决的是内存上限两者需要组合使用只有max没有ttl数据可能长时间陈旧只有ttl没有max内存可能失控。从lru-cache的实现语义看get命中条目时还会将该条目标记为最近使用使其在淘汰排序中靠后这正是LRULeast Recently Used名称的来源最久没被访问的条目最先被淘汰。缓存键的设计缓存键决定了什么算同一份数据。规则文档示例以id作为键这是最直接的形态但实际项目中还需注意键必须能唯一定义数据例如按用户维度缓存时用user:${userId}按用户资源维度缓存时用${userId}:${resourceId}避免不同语义的数据互相覆盖避免把完整对象作为键对象键会涉及引用相等性问题与 server-cache-react.md 中React.cache()使用Object.is浅比较的坑类似应使用原始值或规范化后的字符串键键命名空间化多个缓存职责共享一个实例时用前缀如user:、config:隔离防止碰撞也便于在排查问题时按前缀过滤。运行模型差异Fluid Compute 与 Serverless 的取舍规则文档专门讨论了缓存效果与部署运行模型的强耦合关系这是理解本规则何时有效的关键Vercel Fluid Compute进程内缓存天然跨请求共享With Vercels Fluid Compute: LRU caching is especially effective because multiple concurrent requests can share the same function instance and cache. This means the cache persists across requests without needing external storage like Redis.在 Vercel Fluid Compute 模型下多个并发请求可以共享同一个函数实例与其中的缓存。因此进程内的 LRU 缓存能够跨请求持续存活无需引入 Redis 等外部存储即可获得显著的缓存命中率模块级缓存含 LRU 实例的收益被放大——同一实例上连续到达的请求直接命中内存。这与同板块的另一条规则 server-hoist-static-io.md 的论断一致该规则同样指出 Fluid Compute 下模块级资源字体、Logo可跨请求常驻内存without cold start penalties。传统 Serverless每次调用隔离进程内缓存无效In traditional serverless: Each invocation runs in isolation, so consider Redis for cross-process caching.在传统 Serverless 模型下每次函数调用都在相互隔离的环境中运行进程内缓存无法跨调用复用。此时LRU 缓存退化为单次调用内有效失去跨请求意义规则文档明确建议改用 Redis 等外部存储实现跨进程缓存需要权衡的外部缓存设计点Redis 键的 TTL、缓存穿透保护同一热点键并发回源、缓存雪崩大量键同时过期等。换言之选用进程内 LRU 还是外部 Redis首先取决于运行平台其次才是数据特征。若应用部署在可复用实例的平台上Fluid Compute、Node 常驻进程、Kubernetes Pod 等LRU 是零额外依赖的高性价比方案若部署在纯 Serverless 上则必须外置缓存。边界与组合与相邻规则的协同LRU 缓存不是孤立的技巧它与服务端性能板块的其他规则构成一套组合拳。以下是规则文档及其相邻规则共同勾勒出的边界与React.cache()的边界server-cache-react.mdReact.cache()面向请求内去重LRU 面向跨请求复用实践中可以叠加使用先在外层用 LRU 缓存跨请求命中再用React.cache()包裹以在单个请求内进一步去重LRU 命中后的结果在同一请求内多次读取只取一次Next.js 环境下fetch自带请求记忆化request memoization同 URL 同参数的fetch在单请求内自动去重因此React.cache()主要服务于数据库查询、重计算、鉴权、文件系统等非 fetch 异步操作LRU 缓存则适用于这些操作的跨请求维度。与禁止共享模块状态的边界server-no-shared-module-state.md该规则警告不要用模块级可变变量传递请求级数据因为服务端渲染可并发执行写共享状态会导致竞态、跨请求污染甚至安全漏洞。LRU 缓存之所以是安全的例外是因为它以键寻址不同请求读取自己的键互不覆盖值应当是与请求无关的共享数据用户资料、配置等而不是当前请求的临时状态具备淘汰与过期机制不会无限累积。反过来若把当前请求的用户上下文存进 LRU 缓存并错误地复用于其他请求就违背了该规则的精神属于应当避免的误用。与提升静态 I/O的边界server-hoist-static-io.md完全静态、永不变更的资产字体、Logo、模板应提升到模块级只加载一次无需 TTL会变化但低频的数据配置、用户资料适合LRU TTL该规则的不适用场景清单也给出了对照按请求或用户变化的资产不要做静态提升而应走带键的缓存或按需获取运行期可能变化的文件要用带 TTL 的缓存——这正是 LRU 缓存的用武之地。参考与实践指引本规则的完整实现与说明可在仓库以下文件中继续深入规则原文skills/vendor/react-best-practices/rules/server-cache-lru.md请求内去重对照规则skills/vendor/react-best-practices/rules/server-cache-react.md共享模块状态红线skills/vendor/react-best-practices/rules/server-no-shared-module-state.md静态 I/O 提升skills/vendor/react-best-practices/rules/server-hoist-static-io.md规则集合总览skills/vendor/react-best-practices/README.md、skills/vendor/react-best-practices/AGENTS.md依赖清单含lru-cache引用skills/vendor/react-best-practices/metadata.json落地时建议按以下清单自查该数据是否会被多个连续请求共享——是才用跨请求缓存否则用React.cache()即可运行平台是否支持实例复用——支持进程内 LRU 即可纯 Serverless 请改用 Redis 等外部存储是否同时设置了max与ttl——两者缺一不可分别防内存失控与数据陈旧缓存键是否唯一且不含请求级可变状态——确保不违反禁止共享模块状态规则数据变更时如何失效——必要时提供显式cache.delete(key)或cache.clear()的更新路径避免脏读。【免费下载链接】OpenMetadataThe Open Context Layer for Data and AI , OpenMetadata is the open platform for building trusted data context and business semantics for humans, AI assistants, and agents.项目地址: https://gitcode.com/GitHub_Trending/op/OpenMetadata创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考