![[Redis小技巧17]深入解析 Redis 缓存穿透：原理、防御策略与布隆过滤器实践](images/news1.jpg)
在高并发系统中缓存是提升性能、降低数据库负载的关键组件。然而缓存并非万能——当恶意请求或异常流量持续查询不存在的数据时缓存层无法命中所有请求直击后端数据库导致系统雪崩式崩溃。这种现象被称为“缓存穿透”Cache Penetration。一、什么是缓存穿透缓存穿透指客户端持续请求根本不存在于数据库中的数据如user_id -1或随机生成的无效 ID由于这些数据既不在缓存中也不在数据库中每次请求都会绕过缓存直达数据库造成数据库压力剧增甚至宕机。典型场景黑客恶意攻击构造大量非法 ID前端传参校验缺失用户输入无效查询条件爬虫遍历非连续主键空间。二、缓存穿透 vs 缓存击穿 vs 缓存雪崩为避免混淆我们先厘清三个高频概念问题类型触发原因影响范围防御手段缓存穿透查询不存在的数据单点/批量无效请求空值缓存、布隆过滤器缓存击穿热点 key过期瞬间被大量并发访问单个热点 key互斥锁、逻辑过期、永不过期缓存雪崩大量 key同时过期或缓存节点宕机全局性随机 TTL、多级缓存、高可用部署关键区别穿透是“查无此物”击穿是“热点失效”雪崩是“集体失效”。三、防御缓存穿透的两大核心方案方案 1空值缓存Null Caching原理当查询数据库返回空结果时仍将该 key 写入 Redisvalue 可设为特殊标记如NULL并设置较短 TTL如 30–300 秒。Redis 命令示例# 查询用户GET user:999999# 返回 nil → 查询 DB → DB 也无此用户# 写入空值缓存SET user:999999NULLEX60优点实现简单无需额外依赖有效拦截重复无效请求。风险与注意事项内存浪费若攻击者使用海量不同无效 ID可能撑爆缓存TTL 设计不宜过长避免脏数据也不宜过短失去防护意义清理策略建议配合 LRU 或定期清理脚本。方案 2布隆过滤器Bloom Filter原理布隆过滤器是一种概率型数据结构用于快速判断“某元素是否可能存在于集合中”。它由一个位数组和多个哈希函数组成。若 BF 返回“不存在”→ 数据一定不存在100% 准确若 BF 返回“可能存在”→ 需进一步查缓存或 DB存在误判。在 Redis 中的实现Redis 官方通过RedisBloom 模块提供原生支持需单独加载# 添加元素BF.ADD user_ids1001BF.ADD user_ids1002# 查询是否存在BF.EXISTS user_ids999999# 返回 0 → 一定不存在BF.EXISTS user_ids1001# 返回 1 → 可能存在需查缓存优势空间效率极高1 亿条数据仅需 ~100MB查询速度极快O(k) 时间复杂度k 为哈希函数数量天然防穿透无效 ID 在 BF 层即被拦截。局限性存在误判率可通过参数调整如error_rate0.01不支持删除可改用 Counting Bloom Filter但 RedisBloom 默认不支持需预加载全量合法 ID适用于 ID 集合相对稳定的场景如用户表、商品 SKU。实战演示布隆过滤器如何工作1. 核心思想用“位”代替“值”传统集合如 HashSet存储元素本身而布隆过滤器不存元素只用一个位数组bit array和多个哈希函数来“标记”某个元素“可能被加入过”。它回答的是“这个元素一定不存在” →100% 准确“这个元素可能存在” →可能误判False Positive。2. 布隆过滤器的组成一个长度为 m 的位数组初始全为 0k 个独立的哈希函数如 MurmurHash、FNV 等每个函数将输入映射到[0, m-1]的整数3. 实际操作流程步骤 1添加元素ADD假设我们要添加元素apple用 k 个哈希函数分别计算hash1(apple) 3hash2(apple) 17hash3(apple) 99将位数组的第 3、17、99 位设为 1位数组部分 索引: ... 3 ... 17 ... 99 ... 值: ... 1 ... 1 ... 1 ...注意不存储 “apple” 本身只记录它的“指纹位置”。步骤 2查询元素EXISTS现在查询banana是否存在用同样的 k 个哈希函数计算hash1(banana) 5hash2(banana) 17hash3(banana) 88检查位数组的第 5、17、88 位如果任意一位是 0→“banana” 一定不存在如果所有位都是 1→“banana” 可能存在但可能是其他元素“污染”了这些位4. 举例说明误判False Positive先加入apple→ 设置位 3, 17, 99 为 1再加入orange→ 假设计算得位 5, 17, 200 为 1现在位 17 已被两个元素共用此时查询cherry若其哈希结果恰好是3, 5, 17而这三个位都已被设为 1尽管cherry从未加入布隆过滤器就会误判为“可能存在”。但只要有一个位是 0就100% 确定不存在——这是布隆过滤器最强大的特性。5. 可视化流程图6. 关键数学关系决定性能的核心布隆过滤器的效果由三个参数决定参数含义n预期插入的元素数量m位数组长度bit 数k哈希函数个数最优哈希函数数量kmnln2 k \frac{m}{n} \ln 2knmln2误判率False Positive Ratep≈(1−e−knm)k p \approx \left(1 - e^{-\frac{kn}{m}}\right)^kp≈(1−e−mkn)k实践建议若你预计存100 万个 ID希望误判率 ≤1%则所需位数组大小m ≈ 9.6 MB约 958 万 bits哈希函数数量k ≈ 7RedisBloom 的BF.RESERVE命令正是基于此公式设计BF.RESERVE my_bf0.011000000# 1% 误判率100 万容量7. 现实中的限制与应对限制说明应对方案不能删除元素清除某 bit 会影响其他元素改用Counting Bloom Filter每个位用计数器代替必须预估容量超出容量后误判率飙升监控BF.INFO或使用可扩展 BF如 Scalable Bloom Filter不支持精确查询只能做“存在性”初筛后续仍需查缓存或 DB 确认布隆过滤器就像一个“超级快速的黑名单筛查员”它能 100% 确认“坏人不在名单里”但说“可能是好人”时你需要再查身份证确认。实战演示Redis 原生支持RedisBloom 模块Redis 自 4.0 起支持模块机制RedisBloom是官方推荐的布隆过滤器实现需单独加载。1. 常用命令命令说明BF.RESERVE key error_rate capacity [expansion]创建 BF指定误判率与容量BF.ADD key item添加单个元素BF.MADD key item1 item2 ...批量添加BF.EXISTS key item判断是否存在BF.MEXISTS key item1 item2 ...批量判断BF.INFO key查看内部状态容量、插入数、哈希函数数等注意若未显式RESERVE首次ADD会自动创建默认capacity1000,error_rate0.01。2. 示例# 创建一个容量 10000、误判率 1% 的 BFBF.RESERVE user:exists0.0110000# 添加用户 IDBF.ADD user:exists u12345 BF.ADD user:exists u67890# 查询BF.EXISTS user:exists u12345# 返回 1可能存在BF.EXISTS user:exists u99999# 返回 0一定不存在3. 如何验证 Redis 服务器已加载 RedisBloom 模块在使用 Redis 布隆过滤器前首要前提是确认 Redis 服务端已正确加载 RedisBloom 模块。否则执行BF.ADD等命令会返回 “unknown command” 错误。方法一使用MODULE LIST命令这是最权威、无副作用的检查方式。通过任意 Redis 客户端如redis-cli执行MODULE LIST若输出包含如下内容说明 RedisBloom 已加载1)1)name2)bf3)ver4)702095)path6)/opt/redisbloom/redisbloom.so其中name: bf是 RedisBloom 模块的标识符。若返回空数组(empty array)则表示未加载任何模块包括 RedisBloom。提示该命令无需权限且不会修改任何数据适合在生产环境安全使用。方法二尝试执行布隆过滤器命令快速验证直接调用一个 RedisBloom 特有命令进行试探BF.ADD __test_bf__ item1成功返回(integer) 1或OK→ 模块已加载返回(error) ERR unknown command BF.ADD→ 模块未加载。注意此操作会创建一个临时 key建议命名为__test_bf__并立即删除DEL __test_bf__方法三检查 Redis 配置或启动日志如果有服务器访问权限可进一步确认模块是否被配置加载查看redis.conf是否包含loadmodule /path/to/redisbloom.so查看启动日志如 systemd 或 Docker 日志journalctl-uredis|grep-ibloom# 或dockerlogsredis-container|grepModule bf成功加载时通常会输出Module bf loaded from /path/to/redisbloom.so不推荐的方法依赖INFO命令虽然INFO SERVER能显示 Redis 版本和模式但不会明确列出已加载的模块因此无法用于可靠判断。快速决策表场景推荐方法开发/测试环境快速验证BF.ADD 删除测试 key生产环境安全检查MODULE LIST运维排查部署问题检查redis.conf 启动日志四、请求流程图解含防护机制带布隆过滤器的典型请求链路说明布隆过滤器作为第一道防线空值缓存作为第二道补充形成双重防护。五、常用 Redis 命令速查表场景命令示例说明空值缓存写入SET invalid_key NULL EX 60TTL 建议 30–300s布隆过滤器初始化BF.RESERVE user_bf 0.01 1000000误判率 1%容量 100 万添加合法 IDBF.ADD user_bf 12345批量可用BF.MADD查询是否存在BF.EXISTS user_bf 99999返回 0/1查看 BF 信息BF.INFO user_bf查看 size、capacity 等注RedisBloom 模块需在启动时加载或通过MODULE LOAD动态加载。六、高频面试题Q1如何防止 Redis 缓存穿透答主要两种方式(1) 对查询结果为空的 key 写入短 TTL 的空值缓存(2) 使用布隆过滤器在缓存前拦截非法请求。两者可结合使用。Q2布隆过滤器为什么会有误判能删除元素吗答误判源于多个 key 的哈希值可能映射到位数组的相同位置导致“假阳性”。标准布隆过滤器不支持删除因为多个元素可能共享同一个 bit 位。若清零某一位可能导致其他合法元素被误判为“不存在”破坏“无漏判”特性。若需删除可使用 Counting Bloom FilterRedisBloom 社区版部分支持。Q3空值缓存会不会被恶意利用打爆内存答会。因此应限制空值缓存的 TTL并配合布隆过滤器减少无效 key 写入。也可对 key 做合法性校验如 ID 0前置过滤。Q4布隆过滤器适合什么场景答适合静态或缓慢变化的集合如用户 ID、商品 SKU、黑名单且能接受少量误判的场景。不适合频繁增删或要求 100% 精确的场景。
[Redis小技巧17]深入解析 Redis 缓存穿透：原理、防御策略与布隆过滤器实践
在高并发系统中缓存是提升性能、降低数据库负载的关键组件。然而缓存并非万能——当恶意请求或异常流量持续查询不存在的数据时缓存层无法命中所有请求直击后端数据库导致系统雪崩式崩溃。这种现象被称为“缓存穿透”Cache Penetration。一、什么是缓存穿透缓存穿透指客户端持续请求根本不存在于数据库中的数据如user_id -1或随机生成的无效 ID由于这些数据既不在缓存中也不在数据库中每次请求都会绕过缓存直达数据库造成数据库压力剧增甚至宕机。典型场景黑客恶意攻击构造大量非法 ID前端传参校验缺失用户输入无效查询条件爬虫遍历非连续主键空间。二、缓存穿透 vs 缓存击穿 vs 缓存雪崩为避免混淆我们先厘清三个高频概念问题类型触发原因影响范围防御手段缓存穿透查询不存在的数据单点/批量无效请求空值缓存、布隆过滤器缓存击穿热点 key过期瞬间被大量并发访问单个热点 key互斥锁、逻辑过期、永不过期缓存雪崩大量 key同时过期或缓存节点宕机全局性随机 TTL、多级缓存、高可用部署关键区别穿透是“查无此物”击穿是“热点失效”雪崩是“集体失效”。三、防御缓存穿透的两大核心方案方案 1空值缓存Null Caching原理当查询数据库返回空结果时仍将该 key 写入 Redisvalue 可设为特殊标记如NULL并设置较短 TTL如 30–300 秒。Redis 命令示例# 查询用户GET user:999999# 返回 nil → 查询 DB → DB 也无此用户# 写入空值缓存SET user:999999NULLEX60优点实现简单无需额外依赖有效拦截重复无效请求。风险与注意事项内存浪费若攻击者使用海量不同无效 ID可能撑爆缓存TTL 设计不宜过长避免脏数据也不宜过短失去防护意义清理策略建议配合 LRU 或定期清理脚本。方案 2布隆过滤器Bloom Filter原理布隆过滤器是一种概率型数据结构用于快速判断“某元素是否可能存在于集合中”。它由一个位数组和多个哈希函数组成。若 BF 返回“不存在”→ 数据一定不存在100% 准确若 BF 返回“可能存在”→ 需进一步查缓存或 DB存在误判。在 Redis 中的实现Redis 官方通过RedisBloom 模块提供原生支持需单独加载# 添加元素BF.ADD user_ids1001BF.ADD user_ids1002# 查询是否存在BF.EXISTS user_ids999999# 返回 0 → 一定不存在BF.EXISTS user_ids1001# 返回 1 → 可能存在需查缓存优势空间效率极高1 亿条数据仅需 ~100MB查询速度极快O(k) 时间复杂度k 为哈希函数数量天然防穿透无效 ID 在 BF 层即被拦截。局限性存在误判率可通过参数调整如error_rate0.01不支持删除可改用 Counting Bloom Filter但 RedisBloom 默认不支持需预加载全量合法 ID适用于 ID 集合相对稳定的场景如用户表、商品 SKU。实战演示布隆过滤器如何工作1. 核心思想用“位”代替“值”传统集合如 HashSet存储元素本身而布隆过滤器不存元素只用一个位数组bit array和多个哈希函数来“标记”某个元素“可能被加入过”。它回答的是“这个元素一定不存在” →100% 准确“这个元素可能存在” →可能误判False Positive。2. 布隆过滤器的组成一个长度为 m 的位数组初始全为 0k 个独立的哈希函数如 MurmurHash、FNV 等每个函数将输入映射到[0, m-1]的整数3. 实际操作流程步骤 1添加元素ADD假设我们要添加元素apple用 k 个哈希函数分别计算hash1(apple) 3hash2(apple) 17hash3(apple) 99将位数组的第 3、17、99 位设为 1位数组部分 索引: ... 3 ... 17 ... 99 ... 值: ... 1 ... 1 ... 1 ...注意不存储 “apple” 本身只记录它的“指纹位置”。步骤 2查询元素EXISTS现在查询banana是否存在用同样的 k 个哈希函数计算hash1(banana) 5hash2(banana) 17hash3(banana) 88检查位数组的第 5、17、88 位如果任意一位是 0→“banana” 一定不存在如果所有位都是 1→“banana” 可能存在但可能是其他元素“污染”了这些位4. 举例说明误判False Positive先加入apple→ 设置位 3, 17, 99 为 1再加入orange→ 假设计算得位 5, 17, 200 为 1现在位 17 已被两个元素共用此时查询cherry若其哈希结果恰好是3, 5, 17而这三个位都已被设为 1尽管cherry从未加入布隆过滤器就会误判为“可能存在”。但只要有一个位是 0就100% 确定不存在——这是布隆过滤器最强大的特性。5. 可视化流程图6. 关键数学关系决定性能的核心布隆过滤器的效果由三个参数决定参数含义n预期插入的元素数量m位数组长度bit 数k哈希函数个数最优哈希函数数量kmnln2 k \frac{m}{n} \ln 2knmln2误判率False Positive Ratep≈(1−e−knm)k p \approx \left(1 - e^{-\frac{kn}{m}}\right)^kp≈(1−e−mkn)k实践建议若你预计存100 万个 ID希望误判率 ≤1%则所需位数组大小m ≈ 9.6 MB约 958 万 bits哈希函数数量k ≈ 7RedisBloom 的BF.RESERVE命令正是基于此公式设计BF.RESERVE my_bf0.011000000# 1% 误判率100 万容量7. 现实中的限制与应对限制说明应对方案不能删除元素清除某 bit 会影响其他元素改用Counting Bloom Filter每个位用计数器代替必须预估容量超出容量后误判率飙升监控BF.INFO或使用可扩展 BF如 Scalable Bloom Filter不支持精确查询只能做“存在性”初筛后续仍需查缓存或 DB 确认布隆过滤器就像一个“超级快速的黑名单筛查员”它能 100% 确认“坏人不在名单里”但说“可能是好人”时你需要再查身份证确认。实战演示Redis 原生支持RedisBloom 模块Redis 自 4.0 起支持模块机制RedisBloom是官方推荐的布隆过滤器实现需单独加载。1. 常用命令命令说明BF.RESERVE key error_rate capacity [expansion]创建 BF指定误判率与容量BF.ADD key item添加单个元素BF.MADD key item1 item2 ...批量添加BF.EXISTS key item判断是否存在BF.MEXISTS key item1 item2 ...批量判断BF.INFO key查看内部状态容量、插入数、哈希函数数等注意若未显式RESERVE首次ADD会自动创建默认capacity1000,error_rate0.01。2. 示例# 创建一个容量 10000、误判率 1% 的 BFBF.RESERVE user:exists0.0110000# 添加用户 IDBF.ADD user:exists u12345 BF.ADD user:exists u67890# 查询BF.EXISTS user:exists u12345# 返回 1可能存在BF.EXISTS user:exists u99999# 返回 0一定不存在3. 如何验证 Redis 服务器已加载 RedisBloom 模块在使用 Redis 布隆过滤器前首要前提是确认 Redis 服务端已正确加载 RedisBloom 模块。否则执行BF.ADD等命令会返回 “unknown command” 错误。方法一使用MODULE LIST命令这是最权威、无副作用的检查方式。通过任意 Redis 客户端如redis-cli执行MODULE LIST若输出包含如下内容说明 RedisBloom 已加载1)1)name2)bf3)ver4)702095)path6)/opt/redisbloom/redisbloom.so其中name: bf是 RedisBloom 模块的标识符。若返回空数组(empty array)则表示未加载任何模块包括 RedisBloom。提示该命令无需权限且不会修改任何数据适合在生产环境安全使用。方法二尝试执行布隆过滤器命令快速验证直接调用一个 RedisBloom 特有命令进行试探BF.ADD __test_bf__ item1成功返回(integer) 1或OK→ 模块已加载返回(error) ERR unknown command BF.ADD→ 模块未加载。注意此操作会创建一个临时 key建议命名为__test_bf__并立即删除DEL __test_bf__方法三检查 Redis 配置或启动日志如果有服务器访问权限可进一步确认模块是否被配置加载查看redis.conf是否包含loadmodule /path/to/redisbloom.so查看启动日志如 systemd 或 Docker 日志journalctl-uredis|grep-ibloom# 或dockerlogsredis-container|grepModule bf成功加载时通常会输出Module bf loaded from /path/to/redisbloom.so不推荐的方法依赖INFO命令虽然INFO SERVER能显示 Redis 版本和模式但不会明确列出已加载的模块因此无法用于可靠判断。快速决策表场景推荐方法开发/测试环境快速验证BF.ADD 删除测试 key生产环境安全检查MODULE LIST运维排查部署问题检查redis.conf 启动日志四、请求流程图解含防护机制带布隆过滤器的典型请求链路说明布隆过滤器作为第一道防线空值缓存作为第二道补充形成双重防护。五、常用 Redis 命令速查表场景命令示例说明空值缓存写入SET invalid_key NULL EX 60TTL 建议 30–300s布隆过滤器初始化BF.RESERVE user_bf 0.01 1000000误判率 1%容量 100 万添加合法 IDBF.ADD user_bf 12345批量可用BF.MADD查询是否存在BF.EXISTS user_bf 99999返回 0/1查看 BF 信息BF.INFO user_bf查看 size、capacity 等注RedisBloom 模块需在启动时加载或通过MODULE LOAD动态加载。六、高频面试题Q1如何防止 Redis 缓存穿透答主要两种方式(1) 对查询结果为空的 key 写入短 TTL 的空值缓存(2) 使用布隆过滤器在缓存前拦截非法请求。两者可结合使用。Q2布隆过滤器为什么会有误判能删除元素吗答误判源于多个 key 的哈希值可能映射到位数组的相同位置导致“假阳性”。标准布隆过滤器不支持删除因为多个元素可能共享同一个 bit 位。若清零某一位可能导致其他合法元素被误判为“不存在”破坏“无漏判”特性。若需删除可使用 Counting Bloom FilterRedisBloom 社区版部分支持。Q3空值缓存会不会被恶意利用打爆内存答会。因此应限制空值缓存的 TTL并配合布隆过滤器减少无效 key 写入。也可对 key 做合法性校验如 ID 0前置过滤。Q4布隆过滤器适合什么场景答适合静态或缓慢变化的集合如用户 ID、商品 SKU、黑名单且能接受少量误判的场景。不适合频繁增删或要求 100% 精确的场景。
