【Redis】 缓存三大问题 + 大Key/热Key 全面解析

【Redis】 缓存三大问题 + 大Key/热Key 全面解析 大家好我是程序员二叉。简介本文详解缓存穿透、缓存击穿、缓存雪崩三大经典问题同时讲解 Redis 大 Key、热 Key 的成因与解决方案包含原理、场景、实操方案与业界落地思路适合面试复盘与项目实战。欢迎点赞收藏关注。一、缓存穿透1. 定义查询数据库和缓存中都不存在的数据请求直接绕过缓存持续打到数据库造成数据库压力陡增称之为缓存穿透。2. 产生原因恶意攻击攻击者批量请求不存在的非法 ID、乱造参数。业务异常前端传参错误、爬虫遍历无效数据。空数据未处理不存在的数据没有做缓存兜底。3. 四种解决方案方案1缓存空值空对象/空字符串思路查询数据库发现数据不存在时依然向 Redis 写入一个空标记并设置较短过期时间。优点实现简单、成本低。缺点会占用 Redis 内存短时间大量无效 key 仍会堆积。方案2布隆过滤器思路提前将数据库所有合法主键/有效参数存入布隆过滤器。请求进来先校验过滤器判定不存在则直接拦截不访问缓存与数据库。优点内存占用极小拦截效率高适合海量数据场景。缺点存在误判不支持数据删除传统布隆过滤器数据更新需同步维护过滤器。方案3接口层参数校验与限流思路在网关/接口层做前置拦截校验参数合法性ID 格式、范围、黑名单对异常 IP、高频请求做限流、封禁。优点从入口拦截恶意请求通用性强。缺点无法防范正常参数下的穿透问题。方案4设置互斥空缓存 延时淘汰思路结合分布式锁避免同一无效参数并发穿透空值设置较短过期时间定期清理无效 key控制内存占用。适用中小型业务兼顾性能与内存。组合建议参数校验 布隆过滤器作为主流方案中小项目可直接使用「缓存空值」快速落地。二、缓存击穿1. 定义热点 Key 在缓存过期瞬间大量并发请求同时涌入全部打到数据库该现象称为缓存击穿。特点只针对单个热点 Key区别于雪崩的批量失效。2. 产生原因热点商品、热搜数据等访问量极高的 Key设置了统一过期时间。Key 过期一瞬间海量并发请求绕过缓存直达数据库。3. 解决方案方案1热点数据永不过期物理永不过期思路对核心热点 Key不设置过期时间从根源避免过期击穿。补充业务更新数据时主动更新 Redis 缓存保证数据一致性。优点实现最简单无并发问题。缺点数据长期驻留内存需手动维护更新仅适合变更频率低的热点数据。方案2加分布式互斥锁思路缓存失效后只允许一个请求去查询数据库并更新缓存其他请求等待重试。实现使用 RedisSET NX EX实现分布式锁。执行流程查缓存不存在则尝试加锁加锁成功 → 查询数据库回写缓存释放锁加锁失败 → 短暂休眠后重试查缓存。优点通用性强所有场景均可使用。缺点会产生少量等待并发极高时存在性能损耗需处理锁超时、死锁问题。拓展方案逻辑过期常用优化不删除 Key在 Value 中额外存储逻辑过期时间。线程发现逻辑过期后通过异步线程更新缓存旧数据继续对外提供服务。优点无等待、吞吐量高缺点会短暂存在数据不一致。三、缓存雪崩1. 定义大量缓存 Key 在同一时刻集体失效或 Redis 服务宕机导致海量请求全部压向数据库数据库压力过载甚至宕机连锁引发整个系统崩溃即为缓存雪崩。2. 产生原因批量 Key过期时间集中同一时间大面积失效。Redis 集群宕机、断电、网络故障缓存整体不可用。缓存服务性能瓶颈、响应超时等同于缓存失效。3. 全流程解决方案事前 事中 事后1事前预防优先做成本最低过期时间加随机值给缓存过期时间增加随机偏移量打散过期时间避免集体失效。例基础时长 0~300秒随机值。Redis 高可用架构搭建主从 哨兵或 Redis 集群避免单节点宕机导致整体不可用。热点数据永不过期核心流量数据禁用过期时间从源头规避失效风险。2事中管控故障发生时止损接口限流 熔断降级网关/服务层使用限流组件限制每秒请求量缓存失效触发大量慢查询时开启熔断直接返回兜底数据不再访问数据库。多级缓存引入本地堆缓存Caffeine、Guava 分布式缓存 Redis多层兜底降低 Redis 压力。分布式锁限流针对失效缓存做请求排队控制访问数据库的并发量。3事后恢复故障发生后快速修复快速重启/切换节点Redis 宕机后依靠哨兵自动切换主节点快速恢复缓存服务。缓存预热手动/脚本批量重建热点缓存避免恢复瞬间再次被打垮。故障复盘排查宕机、超时原因优化架构与参数防止重复发生。四、Redis 大 Key 问题1. 什么是大 Key字符串类型Value 体积过大通常建议 10KB 判定为大 Key。集合类型List/Hash/Set/ZSet元素数量极多如 Hash 字段上千、List 元素过万。2. 危害网络传输耗时增加接口响应变慢。内存分配、数据迁移集群分片卡顿阻塞 Redis 主线程。删除大 Key 会产生大量内存释放耗时引发服务阻塞。3. 核心解决方案核心思路拆分横向拆分分 Key 存储将一个大 Key 拆分为多个小 Key。例如海量用户列表按 ID 哈希分段拆分。纵向拆分字段拆分针对 Hash 类型将不常访问的字段拆到独立 Key减少单个 Hash 体量。控制元素数量限制 List/Set/ZSet 最大元素个数超出则分页存储。渐进式删除禁止直接DEL大 Key使用hscan/lscan分批遍历删除避免阻塞主线程。优化数据结构合理选用结构避免盲目使用集合类型存储海量数据。五、Redis 热 Key 问题1. 什么是热 Key某一个 Key 被超高并发访问每秒数万/十万次请求流量集中在单个 Key造成 Redis 单节点压力过载、网卡打满、请求延迟升高。常见场景秒杀商品、首页活动、全网热搜。2. 产生危害Redis 单节点 CPU、网卡、连接数打满影响其他正常 Key。集群环境下流量倾斜分片负载严重不均。3. 主流解决方案含京东 HotKey 探测机制基础通用方案本地缓存兜底在应用层增加堆内本地缓存Caffeine拦截大部分热点请求不打到 Redis。设置短过期时间兼顾一致性与性能。Key 分片复制热点将一个热 Key 复制为多个名称不同、数据相同的 Key分散到集群不同节点分摊流量。请求时随机路由到其中一个分片 Key。请求限流 排队接口层对热 Key 做限流、队列削峰降低并发压力。业界方案京东 HotKey 探测与防护机制京东自研 HotKey 组件分为探测、上报、兜底三部分热 Key 实时探测客户端/代理层Proxy统计每个 Key 的 QPS基于滑动窗口统计访问频率。超过预设阈值则判定为热 Key实时上报至统一控制台。全局热 Key 汇总收集全集群上报的热点 Key形成全局热 Key 清单同步至所有服务节点。多层缓存兜底识别到热 Key 后自动将数据加载到应用本地缓存优先走本地缓存。动态调整分片、自动复制热 Key打散集群流量。流量监控与告警热 Key 持续高位时触发告警运维介入人工优化。补充优化热点数据禁止复杂命令只使用简单读写命令。集群合理分片避免热点固定落在单一节点。总结缓存穿透查不存在的数据 → 方案缓存空值、布隆过滤器、参数校验、分布式空缓存。缓存击穿单个热点 Key 过期 → 方案互斥分布式锁、数据永不过期、逻辑过期。缓存雪崩大量 Key 同时失效/缓存宕机 → 事前打散过期时间、高可用事中限流熔断、多级缓存事后快速恢复、缓存预热。大 Key核心解决思路为拆分 分批删除控制单 Key 数据量。热 Key本地缓存、Key 分片分流业界参考京东 HotKey 做实时探测、全局感知、多层兜底。