在 Redis 缓存架构中，缓存穿透是一个容易被忽视却可能引发严重后果的问题。它如同系统中的 “暗箭”，在缓存与数据库之间撕开一道缺口，让大量无效请求直接冲击底层存储。
缓存穿透指的是查询一个在缓存和数据库中都不存在的数据时，请求绕过缓存直接穿透到数据库的现象。由于缓存无法命中（缓存中无此数据），且数据库也无对应记录，每次这类请求都会直达数据库。举个典型场景：某电商平台的商品查询接口，正常请求会携带合法商品 ID（如 1001、1002），但如果有攻击者持续用不存在的 ID（如 - 999、10000000）发起请求，由于缓存和数据库中都没有这些 ID 对应的记录，所有请求都会直接访问数据库，形成缓存穿透。
缓存穿透的出现并非偶然，主要源于两类场景：
（1）业务逻辑疏漏：
应用程序可能因数据删除、ID 生成规则错误等原因，产生查询不存在数据的合理请求。例如，用户查询已被删除的订单信息，或前端表单校验失效导致的无效 ID 提交。
（2）恶意攻击行为：
攻击者通过构造大量不存在的 Key（如随机生成的用户 ID、商品 ID）发起高频请求，利用缓存穿透特性消耗数据库资源。这类攻击具有隐蔽性强、流量集中的特点，容易对系统造成突发性冲击。
缓存穿透看似只是 “查询无效数据”，但其累积效应可能引发连锁反应：
（1）数据库资源耗尽：大量穿透请求会占用数据库连接池资源，导致正常请求因无法获取连接而超时。
（2）系统响应延迟：数据库在处理无效请求时的开销，会拖慢整体查询响应速度，影响用户体验。
（3）服务可用性下降：极端情况下，数据库可能因过载宕机，导致依赖其提供服务的应用整体崩溃。
针对缓存穿透的特性，目前业界已形成多种成熟解决方案，实际应用中可根据场景组合使用。主要如下：
（1） 缓存空值
当数据库返回空结果时，将空值存入缓存并设置较短过期时间（如 5-60 秒）。这样后续相同请求会从缓存获取空值，避免穿透到数据库。
public Product getProductById(Long id) {
// 1. 先查缓存
String cacheKey = "product:" + id;
String productJson = jedis.get(cacheKey);
if (productJson != null) {
// 缓存命中（包括空值）
return productJson.isEmpty() ? null : JSON.parseObject(productJson, Product.class);
}
// 2. 缓存未命中，查数据库
Product product = productMapper.selectById(id);
if (product != null) {
// 3. 数据库存在，写入缓存（过期时间加随机值防雪崩）
jedis.setex(cacheKey, 3600 + new Random().nextInt(100), JSON.toJSONString(product));
} else {
// 4. 数据库不存在，缓存空值（短过期时间）
jedis.setex(cacheKey, 60, ""); // 空字符串代表不存在
}
return product;
}
// 优点：实现简单，适合突发少量无效请求场景。
// 缺点：可能缓存大量空值键，浪费内存；若过期时间设置不当，会影响数据实时性。（2） 布隆过滤器
布隆过滤器是一种空间效率极高的概率型数据结构，可快速判断元素是否存在于集合中。将数据库中所有有效 Key 存入布隆过滤器，请求到达时先通过过滤器校验，不存在的 Key 直接拦截。
// 1. 初始化布隆过滤器（单例，服务启动时加载所有有效ID）
@Configuration
public class BloomFilterConfig {
@Bean
public BloomFilter<Long> productIdBloomFilter(ProductMapper productMapper) {
// 加载数据库中所有有效商品ID
List<Long> allProductIds = productMapper.selectAllIds();
// 预计数据量100万，误判率0.01
BloomFilter<Long> filter = BloomFilter.create(Funnels.longFunnel(), 1000000, 0.01);
allProductIds.forEach(filter::put);
return filter;
}
}
// 2. 在查询接口中使用
@Service
public class ProductService {
@Autowired
private BloomFilter<Long> productIdBloomFilter;
public Product getProductById(Long id) {
// 1. 布隆过滤器校验，不存在直接返回
if (!productIdBloomFilter.mightContain(id)) {
return null;
}
// 2. 后续流程同缓存空值方案（查缓存→查数据库→更新缓存）
// ...省略代码...
}
}
//优点：拦截效率高，适合海量数据场景，内存占用远低于缓存空值。
/*缺点：存在一定误判率（可通过参数调整）；需维护过滤器与数据库的一致性（如新增数据时同步更新过滤器）。*/（3）接口限流与恶意请求拦截
通过限流工具（如 Sentinel、Redis 限流器）限制接口单位时间内的请求量，同时结合风控系统识别恶意 IP 并拉黑。
# Spring Cloud Gateway限流配置示例
spring:
cloud:
gateway:
routes:
- id: product_route
uri: lb://product-service
predicates:
- Path=/product/**
filters:
- name: RequestRateLimiter
args:
redis-rate-limiter.replenishRate: 50 # 稳定速率（每秒50个请求）
redis-rate-limiter.burstCapacity: 100 # 突发容量
key-resolver: "#{@ipKeyResolver}" # 按IP限流缓存穿透的本质是 “无效请求的无成本穿透”，解决思路核心在于增加无效请求的穿透成本—— 无论是通过缓存空值消耗内存，还是布隆过滤器消耗计算资源，最终目的都是为数据库建立一道 “防护网”。在实际开发中，需结合业务流量特征与系统资源状况，选择最适合的方案。