API接口缓存有效期没有统一的标准答案，先把接口按“能容忍多旧的数据”分级，再给读多写少接口秒级到分钟级TTL，强一致接口尽量短或不缓存，并用主动失效兜底，才能在性能和一致性之间取得平衡。 缓存有效期本质上是业务对数据新鲜度的承诺,不是随手填一个数字就完事。
API缓存有效期设置多少合适？先把一致性底线划出来
缓存有效期设置多少，先别急着看Redis配置项，你真正要回答的是：这个接口返回旧数据5秒、30秒、5分钟，业务能不能接受，能接受，TTL才有意义；不能接受,缓存就不该放在关键路径上。
缓存有效期与数据一致性如何平衡
一致性不是非黑即白，行业共识认为，缓存一致性要按业务容忍度分级，而不是所有接口都追求强一致,可以分成三类：
- 强一致场景：余额扣减、库存扣减、支付状态、订单终态，这类接口建议TTL为0到5秒，甚至不缓存，写路径直接落库,读路径用版本号或主动失效兜底。
- 最终一致场景：商品详情、文章内容、配置项，TTL可以放到60到300秒，写后删缓存,配合消息队列或变更日志异步失效。
- 弱一致场景：排行榜、推荐列表、非关键统计，TTL放到5到30分钟也能接受,过期后异步刷新即可。
下面这张表可以直接作为配置评审的起点：
| 接口类型 | 数据容忍度 | 建议TTL | 一致性策略 | 失效方式 |
|---|---|---|---|---|
| 商品详情 | 可容忍短暂旧数据 | 60-300秒 | 最终一致 | 过期删除+写后删 |
| 用户会话 | 中等 | 5-30分钟 | 会话一致 | 主动失效 |
| 库存余额 | 低 | 0-5秒或不缓存 | 强一致 | 主动失效+版本号 |
| 排行榜推荐 | 高 | 5-30分钟 | 弱一致 | 过期删除 |
这张表不是让你照抄，而是提醒你：TTL越长，回源越少，旧数据窗口越大,真正要定的是窗口大小。
过期删除、主动失效、延迟双删怎么选
三种策略解决的不是同一个问题。
- 过期删除：实现最简单，适合能容忍旧数据的接口，Redis里一条命令就能设置：
SET product:1001 "{...}" EX 120。 - 主动失效：写数据库后删缓存，适合一致性要求高的接口，常用路径是“先更新数据库，再删除缓存”，命令为
DEL product:1001。 - 延迟双删：更新数据库前后各删一次，适合并发写较多的场景，第二次删除可以延迟几百毫秒,降低旧值回填概率。
实操上，Cache Aside模式最常用：读缓存未命中就查数据库并回填，写操作更新数据库后删缓存，别在写路径里直接改缓存值,除非你能接受并发覆盖带来的不一致。
高并发场景下API缓存有效期怎么配置
高并发场景不能只靠一个TTL，热点商品、秒杀库存、活动页接口,建议组合使用：
- 短TTL+本地缓存：本地缓存TTL设1到5秒，分布式缓存设10到60秒,减少跨网络调用。
- 空值缓存：查不到的数据也缓存30到60秒,防止缓存穿透。
- 互斥锁重建：缓存失效时只放一个请求回源，命令如
SET lock:product:1001 1 NX EX 10。 - 逻辑过期：value里带
expireAt，过期后先返回旧值，再异步刷新,避免大量请求同时击穿。
如果你正在做北京API接口缓存优化方案，跨可用区调用延迟会让TTL选择更谨慎，本地缓存通常更短，分布式缓存承担兜底；北京地域多可用区部署时，还要把跨区延迟算进“旧数据窗口”,别让一个短TTL被网络抖动放大成频繁回源。
API缓存有效期设置要花钱吗
缓存有效期本身不单独收费，成本来自缓存实例的内存、带宽和回源压力，TTL长，内存占用相对高，但数据库压力小；TTL短，回源请求多，数据库和下游服务成本上升，北京地域的云资源价格和SLA有差异，选型时看预算和稳定性要求，不必为了省一点内存把TTL拉得过长，业内专家指出，缓存成本要按“内存+回源+故障风险”一起算,单看实例价格容易失真。
一套可执行的TTL配置流程
别在代码里随手写expire 60，按下面顺序走,配置才有依据。
- 给接口分级：列出强一致、最终一致、弱一致接口,标注数据旧多久会引发客诉或资损。
- 定初始TTL：强一致接口先不缓存或设1到5秒；最终一致接口从60秒起步；弱一致接口从5分钟起步。
- 加主动失效：写操作后删缓存，关键字段带版本号,版本变化时缓存key同步变化。
- 加随机抖动：
EX 120改成EX 120+随机0到30秒,避免同一批key同时过期引发缓存雪崩。 - 压测和灰度：先灰度10%流量，观察回源QPS、缓存命中率和旧数据投诉。
- 监控告警：Redis用
INFO stats看keyspace_hits和keyspace_misses；Nginx看$upstream_cache_status的HIT、MISS、EXPIRED比例。
Nginx侧可以这样配：
location /api/product {
proxy_cache api_cache;
proxy_cache_valid 200 60s;
proxy_cache_key $scheme$request_method$host$request_uri;
add_header X-Cache-Status $upstream_cache_status;
}
这里proxy_cache_valid 200 60s就是给成功响应设60秒TTL，路径清楚,改起来也直观。
四个容易踩的坑
- TTL写死同一值：同一批热点key同时过期，数据库瞬间被打穿,加随机抖动。
- 只设过期不做主动失效：商品价格改了，缓存还要等几分钟才更新,客诉就来了。
- 缓存穿透不处理：恶意请求不存在的ID，每次都打数据库,空值缓存和布隆过滤器要上一个。
- 监控只看命中率：命中率高不代表一致性好，还要看旧数据比例和失效延迟，近年来不少团队复盘线上问题时发现,缓存失效策略不当会放大数据库压力。
据工信部云计算相关公开信息，近年来企业接口服务化程度持续提升，缓存几乎成了API网关的标配能力，能力越标配,越要把TTL当成业务契约来管理。
把缓存有效期当成业务契约的一部分，而不是一个随手填的配置项，数据一致性才有抓手，先定容忍度，再定TTL，最后用主动失效和监控兜底，这套顺序比追求某个“最佳秒数”更可靠。
Q&A：API缓存有效期与数据一致性常见问题
API缓存有效期设置越长越好吗？
不是，TTL越长，回源越少，但旧数据窗口越大，读多写少、能容忍旧数据的接口可以拉长到分钟级；库存、余额、支付状态这类接口要短TTL甚至不缓存，判断标准是业务能不能接受旧数据,不是缓存命中率好不好看。
缓存和数据库不一致时先删缓存还是先更新数据库？
常用做法是先更新数据库，再删除缓存，这样多数读请求能拿到新数据，旧缓存被删后下次读会回填，并发写高的场景可以加延迟双删，第二次删除放在几百毫秒后，降低旧值回填概率，不要先删缓存再更新数据库,中间窗口容易被旧值重新填满。
强一致接口能不能用缓存？
强一致接口可以用缓存，但只能作为只读副本且TTL极短，写路径必须绕过缓存并主动失效；资金扣减这类操作通常直接读写数据库。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/793587.html
