大数据-49 Redis 缓存非常全攻略：穿透、击穿、雪崩、热Key、大Key通杀指南

点一下关注吧！！！非常感谢！！连续更新！！！

🚀 AI篇连续更新中！（恒久更新）

AI炼丹日记-30-新发布【1T 万亿】参数量大模子！Kimi‑K2开源大模子解读与实践，连续打造实用AI工具指南！📐🤖
💻 Java篇正式开启！（300篇）

现在2025年07月21日更新到：
Java-77 深入浅出 RPC Dubbo 负载均衡全剖析：战略、设置与自界说实现实战
MyBatis 已完结，Spring 已完结，Nginx已完结，Tomcat已完结，分布式服务正在更新！深入浅出助你打牢底子！
📊 大数据板块已完成多项干货更新（300篇）：

包罗 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！
大数据-278 Spark MLib - 底子先容 呆板学习算法 梯度提升树 GBDT案例 详解

章节内容

上节我们完成了：

• Redis 通讯协议
  
• Redis 相应模式：串行模式、双工模式
  
• Redis 数据格式
  
• 处理惩罚流程、处理惩罚机制、文件变乱
  
• Reactor 多路复用等底子概念
  

缓存穿透

题目形貌

在标准的缓存体系架构中，当应用步调必要获取某个数据时，会先按照Key去缓存层查询。假如缓存中不存在对应的Value（缓存未掷中），体系就会向后端数据库发起查询哀求。
在高并发场景下，假如大量哀求同时查询一个根本不存在的数据（如恶意攻击者故意构造的随机Key），就会导致以下严厉结果：

• 这些无效哀求会直接穿透缓存层，全部落到数据库上
  
• 数据库必要处理惩罚远超其负载本领的查询哀求
  
• 终极大概导致数据库毗连池耗尽，体系相应变慢以致完全宕机
  

办理方案

1. 空结果缓存

• 实行方式：当查询某个Key返回空结果时，仍然将这个"空结果"存入缓存
  
• 缓存时间设置：
  
  
  
  • 可以设置较短的TTL（如30-60秒）
    
  • 大概在Key对应的数据被INSERT操纵后自动清算该缓存
    
  
  
• 上风：简朴直接，不必要引入额外组件
  
• 实用场景：实用于业务数据量不大，且空查询相对固定的场景
  

2. 布隆过滤器

• 实现原理：
  
  
  • 在缓存层之前增长布隆过滤器层
    
  • 将全部有效Key预先存入布隆过滤器
    
  • 查询时先查抄布隆过滤器
    
  
  
• 工作流程：
  
  
  
  • 哀求到达时，先在布隆过滤器中查抄Key是否存在
    
  • 假如布隆过滤器返回"不存在"，则直接返回空结果
    
  • 只有布隆过滤器返回"大概存在"时，才继承查询缓存/数据库
    
  
  
• 留意事项：
  
  
  
  • 大概存在肯定的误判率（但不会漏判）
    
  • 必要定期重修布隆过滤器以同步数据变动
    
  
  
• 实用场景：实用于数据量大、且空查询较多的场景
  

3. 额外防护步伐（增补）

• 接口限流：对查询接口实行限流步伐，防止大量并发哀求
  
• 参数校验：对查询Key做格式校验，过滤显着不合法的哀求
  
• 热门监控：实时监控体系热门，实时发现非常查询模式
  

布隆过滤器

布隆过滤器（Bloom Filter）是由 Burton Howard Bloom 在1970年提出的，它是一种空间服从极高的概率型数据结构。其核心由两部门构成：一个很长的二进制向量（位数组）和一系列独立且匀称分布的随机哈希函数。
根本原理

• 初始化阶段：
  
  
  
  • 创建一个长度为m的位数组，全部位初始化为0
    
  • 选择k个差异的哈希函数，每个函数都能将输入元素映射到位数组的某个位置
    
  
  
• 添加元素：
  
  
  
  • 当添加一个新元素时，通过k个哈希函数盘算出k个哈希值
    
  • 将这些哈希值对应的位数组位置设为1
    
  • 比方：添加元素"hello"，假设3个哈希函数分别映射到位置2、5、9，则将这些位置置1
    
  
  
• 查询元素：
  
  
  
  • 查询元素是否存在时，同样用k个哈希函数盘算k个位置
    
  • 假如恣意一个位置的值为0，则确定该元素不存在
    
  • 假如全部位置都是1，则该元素大概存在（存在误判大概）
    
  
  

特性分析

• 长处：
  
  
  
  • 空间服从极高：相比传统数据结构，可以节流大量存储空间
    
  • 查询时间恒定：无论元素数量多少，查询都是O(k)时间复杂度
    
  • 安全性：存储的是哈希值而非原始数据
    
  
  
• 缺点：
  
  
  
  • 存在误判率（false positive）：大概误判不存在的元素为存在
    
  • 不能删除元素：标准布隆过滤器不支持删除操纵
    
  
  
• 误判率盘算：
  误判率p ≈ (1 - e(-kn/m))k
  此中：
  
  
  
  • m：位数组巨细
    
  • n：已插入元素数量
    
  • k：哈希函数个数
    
  
  

应用场景

• 网页爬虫URL去重：制止重复爬取类似URL
  
• 垃圾邮件过滤：快速判定邮件所在是否在黑名单中
  
• 缓存穿透防护：在查询数据库前先查抄布隆过滤器
  
• 分布式体系：如Cassandra、HBase等数据库用其判定数据是否存在
  

参数优化发起

为了得到最佳性能，发起：

• 位数组巨细m和元素数量n的比例应在10:1左右
  
• 最优哈希函数数量k ≈ (m/n)ln2
  
• 现实使用中通常选择3-5个哈希函数
  

变体改进

• 计数布隆过滤器：通过使用计数器替换二进制位，支持删除操纵
  
• 动态布隆过滤器：可以动态调解巨细以顺应元素数量的变革
  
• 分层布隆过滤器：通过多层过滤进步正确性
  

在现实应用中，布隆过滤器通常作为第一道"防线"，共同其他数据结构使用，在包管性能的同时低沉误判带来的影响。

缓存雪崩

题目形貌

缓存雪崩是指当缓存服务器因重启、宕机或压力过大无法提供服务时，原来应该由缓存负担的哀求会全部涌入数据库。这会导致数据库短时间内蒙受远超其处理惩罚本领的哀求量，终极引发数据库毗连池耗尽、相应延长飙升，以致导致数据库完全瓦解的连锁反应。
范例场景包罗：

• 缓存集群团体重启时
  
• 大量缓存同时失效时（如设置类似逾期时间）
  
• 突发流量导致缓存服务器过载宕机
  
• 网络分区导致缓存不可用
  

办理方案

1. 分散缓存失效时间

• 对于类似业务逻辑的缓存key，不要设置完全类似的逾期时间
  
• 可接纳底子逾期时间+随机偏移量的方式，比方：expireTime = baseTime + random(0, 300)s
  
• 示例：电商商品缓存可设置30分钟±5分钟的随机逾期时间
  

2. 构建多级缓存体系

• 一级缓存：当地缓存（如Caffeine/Guava Cache）
  
• 二级缓存：分布式缓存（如Redis集群）
  
• 三级缓存：恒久化存储（数据库）
  
• 各级缓存设置差异的逾期战略，逐级回源
  

3. 实现缓存高可用

• 摆设Redis Sentinel或Cluster包管服务可用性
  
• 接纳读写分离架构减轻主节点压力
  
• 对缓存举行分片处理惩罚，制止单点故障影响全局
  
• 实行熔断降级机制（如Hystrix），在缓存不可用时快速失败
  

4. 其他优化步伐

• 预热热门数据：在体系低峰期提前加载紧张缓存
  
• 实现互斥锁：制止大量哀求同时重修缓存
  
• 设置缓存永不逾期，通事背景使命定期更新
  
• 监控缓存掷中率，设置自动告警机制
  

缓存击穿

题目形貌

缓存击穿是指在高并发场景下，某些热门数据（设置了逾期时间的key）在缓存刚好逾期的瞬间，忽然有大量并发哀求同时访问这些数据的情况。由于缓存中数据已经逾期失效，这些哀求会直接穿透缓存层，全部打到后端数据库（DB）上，导致数据库瞬时压力骤增，以致大概造成数据库瓦解。
这种情况通常发生在以了局景：

• 电商平台的热门商品页面
  
• 消息网站的突发消息详情页
  
• 秒杀运动中的热门商品信息
  
• 外交平台的热门话题数据
  

这些数据的特点是：

• 访问量非常大
  
• 缓存设置了公道的逾期时间
  
• 在逾期时候轻易形成访问高峰
  

办理方案

1. 分布式锁控制线程访问

实现原理：
当缓存失效时，起首获取分布式锁，只有获取到锁的线程才气访问数据库并重修缓存，其他线程期待或重试。
详细步调：

• 哀求查询缓存，发现数据不存在或已逾期
  
• 实行获取分布式锁（如Redis的SETNX）
  
• 获取锁乐成的线程：
  
  
  
  • 查询数据库获取最新数据
    
  • 将数据写入缓存
    
  • 开释分布式锁
    
  
  
• 获取锁失败的线程：
  
  
  
  • 短暂期待后重试查询缓存
    
  • 大概直接返回默认值/错误信息
    
  
  

长处：

• 有效防止大量哀求同时击穿缓存
  
• 包管数据库不会被瞬间高并发压垮
  

缺点：

• 增长了体系复杂度
  
• 获取锁失败大概导致哀求延长
  

2. 不设置超时时间（永不逾期）

实现方式：

• 缓存数据不设置逾期时间
  
• 通过其他机制包管数据更新
  

更新战略：

• 背景定时使命更新：
  
  
  
  • 定期从数据库获取最新数据
    
  • 异步更新到缓存
    
  
  
• 变乱驱动更新：
  
  
  
  • 当数据库数据变动时
    
  • 通过消息队列关照缓存更新
    
  
  

长处：

• 完全制止缓存击穿题目
  
• 缓存掷中率保持高位
  

缺点：

• 大概导致数据差异等题目
  
• 必要额外的机制包管数据更新
  
• 假如数据更新不实时，用户大概看到逾期数据
  

实用场景：

• 数据变动不频仍的应用
  
• 对实时性要求不高的场景
  
• 可以担当短暂数据差异等的业务
  

其他增补方案

3. 热门数据预加载

在缓存即将逾期前，自动触发缓存重修，制止在逾期时候发生击穿。
4. 二级缓存战略

使用当地缓存+分布式缓存的两级缓存机制，低沉击穿风险。
5. 熔断降级机制

当检测到数据库压力过大时，临时屏蔽部门哀求，掩护体系可用性。
数据差异等题目分析与办理方案

题目形貌

缓存和数据库中的数据差异等是分布式体系中常见的痛点题目。当数据库更新后，缓存未能实时同步更新，导致后续查询获取到逾期数据，严厉影响业务准确性。这种差异等大概由多种缘故原由引起：网络延长、服务宕机、并发操纵等。
办理方案详解

根本方案：延时双删战略

• 初始删除：在更新数据库的同时立即删除缓存。如许当有新哀求进来时，由于缓存未掷中，体系会从数据库读取最新数据并重新添补缓存。
  
• 延时二次删除：在第一次删除后延长2秒（详细时间可根据业务特点调解）再次删除缓存。这个时间隔断是为了处理惩罚极度情况下的并发题目，确保在第一次删除和数据库更新之间大概进来的哀求不会污染缓存。
  
• 设置逾期时间：为全部缓存数据设置公道的逾期时间（TTL），作为末了一道防线，纵然删除操纵失败，缓存终极也会自动失效。
  
• 错误处理惩罚机制：将缓存删除失败的情况纪录到日记体系，然后通过定时使命或监控脚本定期查抄并重试失败的删除操纵。
  

高级方案：Binlog监听

对于要求更高划一性的场景，可以接纳更高级的binlog监听方案：

• 摆设专门的监听服务，订阅数据库的binlog变动变乱
  
• 当监听到数据变动时，立即处理惩罚对应的缓存失效逻辑
  
• 该方案可以大概实现准实时的缓存更新，但实现复杂度较高，必要思量：
  
  
  
  • 监听服务的可用性
    
  • 消息处理惩罚的幂等性
    
  • 非常情况下的赔偿机制
    
  
  

增补发起

• 监控指标：创建缓存差异等的监控指标，实时发现并处理惩罚题目
  
• 压力测试：在高并发场景下测试差异方案的性能体现
  
• 降级战略：当缓存体系出现题目时，要有回退到直接查询数据库的本领
  

并发竞争

题目形貌

多个客户端并发写一个 key，比如写哀求：1、2、3、4，末了原来是4，但是由于到达时间序次题目，成了 2、1、4、3。
办理方案: 分布式锁 + 时间戳

实现原理

预备一个分布式锁，让各人抢锁，抢到再做 SET 操纵。
目标是为了让原来的并行操纵变成串行操纵。

Redis分布式锁

通过 setnx() 函数实现，但是要留意要偶然间：

1. 系统A key 1: {A: 10:00}
2. 系统B key 1: {B: 10:01}

复制代码

假如是B先抢到锁实行后，在A抢到锁后，发现时间已颠末了，那就不做SET操纵了。包管数据的序次。
办理方案：消息队列

在并发量过高的情况下，消息队列列队串行化。
再从消息队列中取出一个一个实行。
HotKey

题目形貌

当有大量的哀求访问某个Redis中的Key，由于流量会合到达网络的上限。
当有大量的哀求（几十万）访问Redis中某个Key时，导致Redis的服务宕机了。接下来就导致流量会进入到DB中。

怎样发现

• 预估热key，比如秒杀、火爆消息
  
• 客户端举行统计
  
• Redis自带下令：monitor、hotkeys，但是实行慢
  
• 使用大数据技能：Storm、Spark、Flink等，发现后写入到ZK中
  

办理方案

• 变分布式缓存为当地缓存，发现hotkey后，加载当地的缓存（数据划一性大概会低）
  
• 在每个主节点上备份呢热key数据，到时间随机选节点读取即可
  
• 热门数据举行限流熔断
  

Big Key

题目形貌

大Key指存储的值非常大：

• 热门话题下的讨论
  
• 大V的粉丝列表
  
• 序列化后的图片
  
• 没有实时处理惩罚的垃圾数据
  

大Key带来的题目：

• 大key会占用大量的内存，集群中无法均衡
  
• Redis性能降落，主从复制非常
  
• 删除时操纵时间过长导致壅闭
  

怎样发现

• 使用 --bigkeys 下令 但key较多时会很慢
  
• 获取 RDB 文件，举行分析
  

怎样处理惩罚

• string范例的bigkey不要存入Redis，可用MongoDB大概CDN
  
• string范例bigkey假如非要存Redis，则单独存储，比如一台Redis单独存。
  
• 将Key拆分成多个 key-value，平摊到多次获取的压力上
  
• 大Key不要del，del会壅闭，而删除时间很长会导致壅闭
  
• 使用 lazy delelet （unlink指令）
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！qidao123.com:ToB企服之家，中国第一个企服评测及软件市场,开放入驻,技术点评得现金