空值缓存ttl应设为60s～180s并配合业务sla，禁用null直存而用"__null__"等明确标记，且必须与接口层参数校验、限流及定期清理协同使用。
空值缓存的TTL不能设成固定 5 分钟
很多人直接抄“TTL=300”，结果在高并发场景下发现缓存里堆满无效空值，内存涨得快、DB 压力没真正降下来。空值 TTL 不是拍脑袋定的，它得和业务查询节奏、数据写入频率、误判容忍度对齐。
-
太短（比如
10s）：攻击者只要每秒发两次相同非法 ID，就又打穿了——刚过期，请求又来，等于白设 -
太长（比如
30min）：新数据刚入库，用户查不到，因为缓存还挂着旧的空值；或者被恶意刷出上万空 key，Redis 内存告警 -
合理区间通常在
60s～180s：覆盖大多数重试/轮询行为，又不至于长期阻塞真实数据生效；若业务有明确“数据写入后多久可查”的 SLA（如“用户注册后 2 分钟内可被搜索”），TTL 应略小于该值
空值内容不能只存 null 或 ""
直接存 redisTemplate.opsForValue().set("user:999999", null, 120, TimeUnit.SECONDS) 会出问题：Spring Data Redis 默认序列化器对 null 处理不一致，有些版本存进去是 nil，取出来变成 "null" 字符串，导致业务逻辑误判为“查到非空数据”。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 统一用明确标记值，比如
"__NULL__"或new byte[0]（空字节数组） - 读取时必须显式判断：
if ("__NULL__".equals(cached)) { return null; }，不能靠== null - 如果用 JSON 序列化器，空值建议序列化为
{"code":404,"msg":"not_found"}这类结构体，避免反序列化失败
空值缓存必须配合接口层校验一起用
只靠空值缓存防穿透，相当于把门锁装在门内侧——外面的人已经进来了。比如攻击者传 id=-1、id=abc、id=9999999999999999999，这些根本不需要查 DB，应该在 Controller 或网关层就拦掉。
- ID 类参数强制校验正整数范围：
if (userId 100000000L) - 字符串类 key 做长度和字符集限制（如只允许数字+字母，长度 ≤ 32）
- 对高频空响应路径（如
/user/{id}）加简单限流：if (rateLimiter.tryAcquire(1, 1, TimeUnit.SECONDS)) { ... } - 空值缓存只是兜底，不是主力防线
别忘了清理过期空值的副作用
Redis 的 EXPIRE 是惰性删除 + 定期抽样，大量空值 key 过期后不会立刻释放内存。如果某天批量导入新用户，但之前被刷过的空 key 还在，就会造成内存虚高、INFO memory 显示 used_memory 持续偏高。
- 上线前用
redis-cli --scan --pattern "user:*" | head -n 10000 | xargs -I {} redis-cli del {}清理测试环境残留 - 生产环境定期跑脚本识别长期未更新的空值 key：
redis-cli --scan --pattern "user:*" | while read k; do ttl=$(redis-cli ttl "$k"); [[ $ttl -lt 10 ]] && echo "$k"; done - 更稳妥的做法是：空值 key 加上命名空间前缀，比如
empty:user:999999，方便后续批量操作
