cache-aside是吞吐量最稳妥的起点，因应用层掌控缓存、避免中间件耦合；需正确实现空值缓存防穿透、随机过期防雪崩、删除而非更新缓存防脏数据，并结合本地缓存提升性能。
Redis缓存策略直接决定系统吞吐量的天花板——选错策略，QPS可能卡在几千；用对模式，5–10万 QPS 是常态。
Cache-Aside 为什么是吞吐量最稳妥的起点
它把缓存控制权交给应用层，避免了中间件耦合，也规避了 Read-Through 中缓存服务自身回源失败导致的级联雪崩。但吞吐量提升效果高度依赖两个动作是否做对：
-
get操作必须带空值缓存（redis.setex("user:999", 300, "")），否则缓存穿透会让数据库瞬间扛住全部无效请求 -
setex的过期时间不能全设成统一值，否则大量 key 同时失效会引发缓存雪崩——建议加随机偏移，比如1800 + random.randint(0, 300) - 写操作必须删除缓存而非更新：用
redis.delete("user:123")，而不是redis.set("user:123", new_data)，否则并发写可能导致脏数据
多级缓存对吞吐量的放大效应在哪
单靠 Redis 很难突破单节点网络 IO 和序列化瓶颈。本地缓存（如 Caffeine）+ Redis 的组合，能把 90% 以上热点请求拦截在进程内，真正打到 Redis 的请求量可能只剩 5%–10%。实测中，三级缓存（Caffeine → Redis Cluster → MySQL）比纯 Redis 方案吞吐量提升 3.2 倍，99 分位延迟从 42ms 降到 7ms。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 本地缓存过期时间要显著短于 Redis（例如 30s vs 5min），否则更新不及时会放大不一致窗口
- 本地缓存更新必须异步触发，否则
localCache.put()同步阻塞会拖慢主流程 - Redis Cluster 分片数建议 ≥ 6，低于这个值容易出现 slot 热点倾斜，某节点 CPU 100% 而其他节点闲置
Write-Through 看似可靠，实际会拖垮吞吐量
它要求每次写都同步落库再回写缓存，看似强一致，但实测在高并发场景下，吞吐量常比 Cache-Aside 低 40%–60%。根本原因是：数据库写入延迟（通常 5–20ms）成了整个链路的瓶颈，Redis 的微秒级能力被白白浪费。
- 仅适合对一致性要求极高、且写频次极低的场景（如用户实名认证状态变更）
- 如果硬要用，必须搭配 pipeline 批量提交，否则单条
SET+ 单条 SQL 的往返开销会指数级放大 - 务必禁用 Redis 的
appendonly yes配置，AOF 日志刷盘会进一步拉长写路径
真正影响吞吐量的从来不是 Redis 本身，而是策略如何与业务读写比例、数据热度分布、故障容忍边界咬合。一个没做空值缓存的 get，一次没加随机过期的 setex，或一个不该用 Write-Through 却用了的写接口，都可能让整套缓存体系吞吐量腰斩。
