尧图网站建设 
NestJS RedisX的SWR与stale-if-error让接口在缓存过期时依然丝滑【免费下载链接】nestjs-redisxModular Redis toolkit for NestJS with plugin architecture - caching, locks, rate limiting, circuit breaker, pub/sub, idempotency, streams, metrics tracing项目地址: https://gitcode.com/gh_mirrors/ne/nestjs-redisx缓存过期的那一刻往往是接口最“卡顿”的时刻大量请求同时打到数据库响应变慢、超时、甚至雪崩。NestJS RedisX作为 NestJS 生态的模块化 Redis 工具包内置了SWRStale-While-Revalidate过期重建与stale-if-error错误时提供过期数据两大缓存策略让接口在缓存过期、甚至后端异常时依然能丝滑响应。本文将用最通俗的方式带你一次看懂这两种缓存策略的原理、配置与最佳实践。缓存过期为何让接口突然卡顿传统的缓存流程很简单缓存有数据就直接返回没有数据就查数据库再写回。问题出在缓存刚好过期的瞬间——数据库压力瞬间飙升高并发下所有请求同时回源响应时间大幅波动缓存命中时 1ms回源时可能 1000ms极端情况引发缓存雪崩大量 key 同时过期数据库直接被压垮。SWR 和 stale-if-error 正是针对这两个痛点设计的一个解决“数据旧一点没关系”的场景一个解决“数据源挂了怎么办”的场景。SWR 是什么过期后先返回旧数据后台悄悄刷新SWR 的全称是 Stale-While-Revalidate直译就是“过期时先返回旧数据同时后台重新验证”。它把缓存的生命周期从一段延长为三段阶段时间范围请求行为新鲜期Freshnow staleAt直接返回缓存零延迟过期窗口StalestaleAt now expiresAt立刻返回旧数据 后台异步刷新完全过期Expirednow expiresAt等待新数据等同缓存未命中在过期窗口内用户几乎无感知响应照常返回NestJS RedisX 的 SWR 管理器会通过setImmediate()在后台非阻塞地执行刷新任务同一 key 同时只允许一个刷新任务自动去重刷新成功后新旧数据无缝衔接。核心实现位于 swr-manager.service.ts其中createSwrEntry()负责计算staleAt与expiresAt时间戳scheduleRevalidation()负责调度后台刷新任务。开启 SWR 的最快配置方法在 NestJS RedisX 中只需在注册CachePlugin时开启一个开关所有使用getOrSet()或Cached的方法即可默认走 SWR 流程new CachePlugin({ swr: { enabled: true, // 全局开启 SWR defaultStaleTime: 60, // 默认过期窗口 60 秒 }, })也可以只针对单个调用开启灵活度很高参考 swr-get-or-set.usage.tsreturn this.cache.getOrSetUser( user:${id}, () this.repository.findOne(id), { ttl: 300, // 新鲜 5 分钟 swr: { enabled: true, staleTime: 300 }, // 过期窗口再延长 5 分钟 } );用装饰器同样生效Cached内部基于getOrSet()实现SWR 能力完全保留Cached({ key: user:{0}, ttl: 300, swr: { enabled: true, staleTime: 300 } }) async getUser(id: string): PromiseUser { ... }stale-if-error后端挂了缓存还能救场如果说 SWR 解决的是新鲜度问题那么 stale-if-error 解决的就是可用性问题当数据加载器比如数据库查询抛错失败时是否允许返回最后一次成功缓存的值它和 SWR 是相互独立的开关拥有独立的窗口。SWR 窗口结束后值还会被保留一段时间keepUntil expiresAt staleIfError.window这段期间它对正常请求不可见——只有加载器抛错时缓存才会兜底返回这个旧值。一个完整的配置示例见 stale-if-error.setup.tsnew CachePlugin({ staleIfError: { enabled: true, defaultWindow: 7 * 24 * 3600, // 后端持续故障时最多兜底 7 天 shouldServe: (error) !/404|410/.test(error.message), // 404 类错误不兜底 }, })三个关键设计值得注意惰性、请求驱动没有后台定时器下次请求触发时才会重试加载器window 必须是有限数字避免 Redis 内存无限增长非法配置会在启动时直接报错可观测每次兜底返回都会输出 warn 日志并累加redisx_cache_stale_if_error_served_total指标故障不会藏在“绿色缓存”背后。SWR 与 stale-if-error 的时间线配合把两个窗口放在同一条时间线上关系一目了然staleAt now ttl # 新鲜 - 过期SWR 开始后台刷新 expiresAt staleAt staleTime # SWR 窗口结束 keepUntil expiresAt staleIfError.window # 仅用于错误兜底staleAt之前直接返回新鲜数据staleAt到expiresAt返回旧数据 后台刷新SWR 生效expiresAt到keepUntil正常请求照常加载新数据只有加载失败才兜底返回旧值stale-if-error 生效。两者可以组合使用并且与缓存插件的**请求合并stampede 防护**天然兼容合并保护负责新鲜加载的并发去重SWR 负责后台刷新stale-if-error 负责故障兜底三层各司其职。最佳实践什么场景该用、什么场景别用推荐使用的场景数据类型推荐 TTL推荐 staleTime总窗口用户资料5 分钟5 分钟10 分钟商品信息1 小时30 分钟1.5 小时配置项24 小时1 小时25 小时搜索结果5 分钟2 分钟7 分钟千万别用的场景安全敏感数据令牌、权限、认证状态——必须永远新鲜库存、余额等强一致数据——旧值可能导致业务错误404/410 类“数据已永久消失”的错误——不要在shouldServe中放行否则已删除的资源会被无限期地“复活”。实用技巧先从较小的staleTime起步根据监控逐步调大长时间故障如半小时以上建议配合 Circuit Breaker 熔断插件让熔断器快速失败、缓存继续兜底组合效果最佳详细的缓存状态与错误处理说明可参考官方文档 swr.md。小结SWR 和 stale-if-error 是缓存系统中“高可用”与“高性能”的黄金组合SWR 让接口在缓存过期时依旧秒回stale-if-error 让接口在数据源故障时依然有值可用。NestJS RedisX 把它们做成了开箱即用的插件开关配置几行即可生效是优化接口响应、抵御缓存雪崩的利器。【免费下载链接】nestjs-redisxModular Redis toolkit for NestJS with plugin architecture - caching, locks, rate limiting, circuit breaker, pub/sub, idempotency, streams, metrics tracing项目地址: https://gitcode.com/gh_mirrors/ne/nestjs-redisx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 NestJS RedisX的SWR与stale-if-error：让接口在缓存过期时依然丝滑
NestJS RedisX的SWR与stale-if-error让接口在缓存过期时依然丝滑【免费下载链接】nestjs-redisxModular Redis toolkit for NestJS with plugin architecture - caching, locks, rate limiting, circuit breaker, pub/sub, idempotency, streams, metrics tracing项目地址: https://gitcode.com/gh_mirrors/ne/nestjs-redisx缓存过期的那一刻往往是接口最“卡顿”的时刻大量请求同时打到数据库响应变慢、超时、甚至雪崩。NestJS RedisX作为 NestJS 生态的模块化 Redis 工具包内置了SWRStale-While-Revalidate过期重建与stale-if-error错误时提供过期数据两大缓存策略让接口在缓存过期、甚至后端异常时依然能丝滑响应。本文将用最通俗的方式带你一次看懂这两种缓存策略的原理、配置与最佳实践。缓存过期为何让接口突然卡顿传统的缓存流程很简单缓存有数据就直接返回没有数据就查数据库再写回。问题出在缓存刚好过期的瞬间——数据库压力瞬间飙升高并发下所有请求同时回源响应时间大幅波动缓存命中时 1ms回源时可能 1000ms极端情况引发缓存雪崩大量 key 同时过期数据库直接被压垮。SWR 和 stale-if-error 正是针对这两个痛点设计的一个解决“数据旧一点没关系”的场景一个解决“数据源挂了怎么办”的场景。SWR 是什么过期后先返回旧数据后台悄悄刷新SWR 的全称是 Stale-While-Revalidate直译就是“过期时先返回旧数据同时后台重新验证”。它把缓存的生命周期从一段延长为三段阶段时间范围请求行为新鲜期Freshnow staleAt直接返回缓存零延迟过期窗口StalestaleAt now expiresAt立刻返回旧数据 后台异步刷新完全过期Expirednow expiresAt等待新数据等同缓存未命中在过期窗口内用户几乎无感知响应照常返回NestJS RedisX 的 SWR 管理器会通过setImmediate()在后台非阻塞地执行刷新任务同一 key 同时只允许一个刷新任务自动去重刷新成功后新旧数据无缝衔接。核心实现位于 swr-manager.service.ts其中createSwrEntry()负责计算staleAt与expiresAt时间戳scheduleRevalidation()负责调度后台刷新任务。开启 SWR 的最快配置方法在 NestJS RedisX 中只需在注册CachePlugin时开启一个开关所有使用getOrSet()或Cached的方法即可默认走 SWR 流程new CachePlugin({ swr: { enabled: true, // 全局开启 SWR defaultStaleTime: 60, // 默认过期窗口 60 秒 }, })也可以只针对单个调用开启灵活度很高参考 swr-get-or-set.usage.tsreturn this.cache.getOrSetUser( user:${id}, () this.repository.findOne(id), { ttl: 300, // 新鲜 5 分钟 swr: { enabled: true, staleTime: 300 }, // 过期窗口再延长 5 分钟 } );用装饰器同样生效Cached内部基于getOrSet()实现SWR 能力完全保留Cached({ key: user:{0}, ttl: 300, swr: { enabled: true, staleTime: 300 } }) async getUser(id: string): PromiseUser { ... }stale-if-error后端挂了缓存还能救场如果说 SWR 解决的是新鲜度问题那么 stale-if-error 解决的就是可用性问题当数据加载器比如数据库查询抛错失败时是否允许返回最后一次成功缓存的值它和 SWR 是相互独立的开关拥有独立的窗口。SWR 窗口结束后值还会被保留一段时间keepUntil expiresAt staleIfError.window这段期间它对正常请求不可见——只有加载器抛错时缓存才会兜底返回这个旧值。一个完整的配置示例见 stale-if-error.setup.tsnew CachePlugin({ staleIfError: { enabled: true, defaultWindow: 7 * 24 * 3600, // 后端持续故障时最多兜底 7 天 shouldServe: (error) !/404|410/.test(error.message), // 404 类错误不兜底 }, })三个关键设计值得注意惰性、请求驱动没有后台定时器下次请求触发时才会重试加载器window 必须是有限数字避免 Redis 内存无限增长非法配置会在启动时直接报错可观测每次兜底返回都会输出 warn 日志并累加redisx_cache_stale_if_error_served_total指标故障不会藏在“绿色缓存”背后。SWR 与 stale-if-error 的时间线配合把两个窗口放在同一条时间线上关系一目了然staleAt now ttl # 新鲜 - 过期SWR 开始后台刷新 expiresAt staleAt staleTime # SWR 窗口结束 keepUntil expiresAt staleIfError.window # 仅用于错误兜底staleAt之前直接返回新鲜数据staleAt到expiresAt返回旧数据 后台刷新SWR 生效expiresAt到keepUntil正常请求照常加载新数据只有加载失败才兜底返回旧值stale-if-error 生效。两者可以组合使用并且与缓存插件的**请求合并stampede 防护**天然兼容合并保护负责新鲜加载的并发去重SWR 负责后台刷新stale-if-error 负责故障兜底三层各司其职。最佳实践什么场景该用、什么场景别用推荐使用的场景数据类型推荐 TTL推荐 staleTime总窗口用户资料5 分钟5 分钟10 分钟商品信息1 小时30 分钟1.5 小时配置项24 小时1 小时25 小时搜索结果5 分钟2 分钟7 分钟千万别用的场景安全敏感数据令牌、权限、认证状态——必须永远新鲜库存、余额等强一致数据——旧值可能导致业务错误404/410 类“数据已永久消失”的错误——不要在shouldServe中放行否则已删除的资源会被无限期地“复活”。实用技巧先从较小的staleTime起步根据监控逐步调大长时间故障如半小时以上建议配合 Circuit Breaker 熔断插件让熔断器快速失败、缓存继续兜底组合效果最佳详细的缓存状态与错误处理说明可参考官方文档 swr.md。小结SWR 和 stale-if-error 是缓存系统中“高可用”与“高性能”的黄金组合SWR 让接口在缓存过期时依旧秒回stale-if-error 让接口在数据源故障时依然有值可用。NestJS RedisX 把它们做成了开箱即用的插件开关配置几行即可生效是优化接口响应、抵御缓存雪崩的利器。【免费下载链接】nestjs-redisxModular Redis toolkit for NestJS with plugin architecture - caching, locks, rate limiting, circuit breaker, pub/sub, idempotency, streams, metrics tracing项目地址: https://gitcode.com/gh_mirrors/ne/nestjs-redisx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考