3. 缓存穿透：穿透原因分析、布隆过滤器原理、布隆过滤器在Redis中的实现
3.1 缓存穿透现象与根因分析
缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，导致每次请求都直接穿透缓存层，落到后端数据库。由于缓存层无法命中，大量恶意或异常请求会直接压垮数据库，造成服务雪崩。
| 对比维度 | 缓存穿透 | 缓存击穿 | 缓存雪崩 |
|---|---|---|---|
| 数据状态 | 缓存与数据库均无数据 | 缓存过期，数据库有数据 | 大量缓存同时过期 |
| 请求特征 | 查询不存在的主键/索引 | 高并发访问单个热点Key | 大量Key同时失效 |
| 根本原因 | 业务层未过滤无效Key | 热点Key过期瞬间并发穿透 | 批量Key过期时间设置相同 |
| 数据库压力 | 每次请求都查库，持续压力 | 瞬间高并发冲击单点 | 瞬时洪峰流量 |
典型穿透场景： 攻击者利用系统漏洞，批量请求不存在的用户ID（如 -1、99999999、'abc'），这些ID在缓存和数据库中均无记录，每次请求都直达数据库，导致数据库连接池耗尽。
3.2 布隆过滤器原理
布隆过滤器（Bloom Filter）是一种空间效率极高的概率型数据结构，用于判断一个元素一定不存在或可能存在于集合中。它由一个位数组和多个哈希函数组成。
核心工作机制
- 初始化： 创建一个长度为 m 的位数组，所有位初始化为 0。
- 添加元素： 使用 k 个独立的哈希函数对元素计算哈希值，将位数组中对应位置的 bit 置为 1。
- 查询元素： 对目标元素计算 k 个哈希值，检查对应位是否全部为 1。若任意一位为 0，则元素一定不存在；若全部为 1，则元素可能存在（存在误判率）。
关键特性：
- 空间效率极高，通常只需传统哈希表 1/10 到 1/100 的内存。
- 支持插入和查询，不支持删除（标准布隆过滤器）。
- 存在误判率（False Positive），但不存在漏判（False Negative）。
- 误判率可通过调整位数组长度 m 和哈希函数个数 k 来控制。
3.3 布隆过滤器在Redis中的实现
Redis 官方提供了 RedisBloom 模块，作为布隆过滤器的标准实现。该模块以插件形式加载到 Redis 中，提供专用的数据结构命令。
3.3.1 安装与加载
# 方式一：使用 Redis Stack（内置 RedisBloom）
docker run -p 6379:6379 redis/redis-stack-server:latest
# 方式二：手动加载模块
redis-server --loadmodule /path/to/redisbloom.so
# 验证模块是否加载成功
127.0.0.1:6379> MODULE LIST
1) 1) "name"
2) "bf"
3) "ver"
4) (integer) 206003.3.2 核心命令与参数
| 命令 | 功能 | 参数说明 |
|---|---|---|
BF.RESERVE |
创建布隆过滤器 | key, error_rate, capacity |
BF.ADD |
添加单个元素 | key, item |
BF.MADD |
批量添加元素 | key, item [item ...] |
BF.EXISTS |
检查元素是否存在 | key, item |
BF.MEXISTS |
批量检查元素 | key, item [item ...] |
BF.INFO |
查看过滤器信息 | key |
3.3.3 实战操作示例
# 1. 创建布隆过滤器：预期容量 10000，误判率 1%
127.0.0.1:6379> BF.RESERVE user_filter 0.01 10000
OK
# 2. 添加用户ID到过滤器
127.0.0.1:6379> BF.ADD user_filter 1001
(integer) 1
127.0.0.1:6379> BF.ADD user_filter 1002
(integer) 1
127.0.0.1:6379> BF.MADD user_filter 1003 1004 1005
1) (integer) 1
2) (integer) 1
3) (integer) 1
# 3. 查询用户是否存在
127.0.0.1:6379> BF.EXISTS user_filter 1001
(integer) 1 # 可能存在
127.0.0.1:6379> BF.EXISTS user_filter 9999
(integer) 0 # 一定不存在
# 4. 查看过滤器状态
127.0.0.1:6379> BF.INFO user_filter
1) Capacity
2) (integer) 10000
3) Size
4) (integer) 11952
5) Number of filters
6) (integer) 1
7) Number of items inserted
8) (integer) 5
9) Expansion rate
10) (integer) 23.3.4 参数选择策略
容量与误判率权衡：
- 容量（capacity）： 预估最大元素数量，设置过小会导致误判率急剧上升。
- 误判率（error_rate）： 推荐 0.01（1%）到 0.001（0.1%），每降低一个数量级，内存消耗约增加 50%。
- 内存计算公式： 位数组长度 m ≈ - (n * ln(p)) / (ln(2))²，其中 n 为元素数量，p 为误判率。
3.4 缓存穿透解决方案对比
| 方案 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 布隆过滤器 | 预加载所有合法Key到过滤器 | 内存占用小，性能高 | 存在误判，不支持删除 | 数据量大、Key集合相对固定 |
| 缓存空对象 | 将空结果也缓存（TTL较短） | 实现简单，无误判 | 占用缓存空间，可能存储大量无效Key | 穿透量不大，Key数量可控 |
| 参数校验 | 在业务层拦截非法参数 | 零额外存储成本 | 只能拦截格式异常请求 | 基础防御，必须配合其他方案 |
| 接口限流 | 限制单位时间请求量 | 保护后端整体稳定性 | 可能误伤正常用户 | 配合布隆过滤器使用 |
3.5 布隆过滤器在调度平台索引选择中的应用
在调度平台中，索引选择器需要频繁判断某个索引键是否存在于已建立的索引集合中。使用布隆过滤器可以快速过滤掉不存在的索引请求，避免无效的索引查找操作。
3.6 最佳实践与避坑指南
常见陷阱：
- 容量预估不足： 布隆过滤器一旦创建，容量不可动态缩减。容量过小会导致误判率飙升，建议按峰值数据量的 1.5~2 倍设置。
- 误判率设置过低： 误判率每降低一个数量级，内存消耗约增加 50%。对于非关键场景，0.01（1%）已足够。
- 忽略数据预热： 布隆过滤器需要在系统启动时加载所有合法 Key，否则上线初期所有请求都会被穿透。
- 不支持删除： 标准布隆过滤器无法删除元素。如果业务需要删除，考虑使用 Counting Bloom Filter 或布谷鸟过滤器。
生产环境推荐配置：
- 预估最大数据量 N = 100 万条
- 误判率 p = 0.01（1%）
- 计算位数组长度：m ≈ - (1,000,000 * ln(0.01)) / (ln(2))² ≈ 9,585,000 bit ≈ 1.14 MB
- 哈希函数个数：k = (m/n) * ln(2) ≈ 6.64，取 7 个
- Redis 命令：
BF.RESERVE my_filter 0.01 1000000