单靠本地缓存或副本key均无法单独解决问题，必须组合使用、控制缓存粒度并明确失效边界；因key一致、过期过长、无空值防护等导致redis节点cpu飙升；副本key需去hash tag、带权重轮询、lua原子写入；一致性靠统一sdk、publish监听及强场景读时校验兜底。
直接结论：单靠客户端本地缓存或副本 Key 都不能单独解决问题，必须组合使用 + 控制缓存粒度 + 明确失效边界。
为什么本地缓存 get 之后还是打爆 Redis？
常见现象是加了 Caffeine 或 Guava Cache，但压测时 Redis 某个节点 CPU 仍飙到 95%+。根本原因不是缓存没生效，而是：
— 缓存 key 和业务 key 完全一致（比如都用 "user:1001"），导致本地缓存未命中时，所有请求仍集中打向同一个 Redis 副本；
— 本地缓存过期时间设得太长（如 5 分钟），而业务要求强一致性，结果缓存还没刷新，Redis 副本已被打穿；
— 没做缓存穿透防护，null 值没缓存，恶意或异常请求反复击穿本地缓存 + Redis。
实操建议：
— 本地缓存 key 应和 Redis key 分离，例如 Redis 存 "user:1001:cache_v2"，本地缓存用 "local:user:1001"；
— 过期时间严格控制在秒级（如 expireAfterWrite(3, TimeUnit.SECONDS)），靠后台线程异步刷新，不阻塞主请求；
— 对空值也缓存（哪怕只缓存 60ms），避免穿透。
副本 Key 怎么拆才不变成“新热点”？
把 "hot_item_123" 拆成 "hot_item_123_copy1" ~ "hot_item_123_copy8" 是常见做法，但容易踩两个坑：
— 所有副本 key 被哈希到同一个 Redis Slot（比如用了 {hot_item_123} 这种 hash tag），结果还是落在一个节点上；
— 客户端随机选副本时没做负载感知，某个副本节点本身已高负载，还继续往里导流。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
实操建议：
— 副本 key 必须去掉 {}，确保哈希计算覆盖整个字符串，例如用 "hot_item_123_copy1_v2" 而非 "hot_item_123{copy1}"；
— 随机策略升级为「带权重的轮询」：根据各副本节点当前 INFO stats|connected_clients 或 latency 动态调整权重；
— 写入时必须原子更新全部副本，推荐用 Lua 脚本封装 SET 多次调用，避免部分成功。
本地缓存 + 副本 Key 组合时，数据一致性怎么兜底？
这是最容易被忽略的复杂点：本地缓存、多个 Redis 副本、数据库四者之间，没有分布式事务。一旦某次更新只写成功 3/4 个副本，或本地缓存没及时失效，就会出现脏读。
实操建议：
— 所有写操作走统一 SDK，强制执行「先删本地缓存 → 并行更新全部 Redis 副本 → 更新 DB」；
— 本地缓存不依赖 Redis 的 TTL，而是监听 Redis 的 PUBLISH hot_key_update 主题（每个副本写成功后发一次），收到消息立即 invalidate；
— 对强一致性场景（如库存），放弃本地缓存，只用副本 Key + 短 TTL + 读时校验（如用 GETEX 带 EX 和 GET 双保险）。
