Redis学习------缓存穿透

        在 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 {@Beanpublic BloomFilter<Long> productIdBloomFilter(ProductMapper productMapper) {// 加载数据库中所有有效商品IDList<Long> allProductIds = productMapper.selectAllIds();// 预计数据量100万，误判率0.01BloomFilter<Long> filter = BloomFilter.create(Funnels.longFunnel(), 1000000, 0.01);allProductIds.forEach(filter::put);return filter;}
}// 2. 在查询接口中使用
@Service
public class ProductService {@Autowiredprivate 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_routeuri: lb://product-servicepredicates:- Path=/product/**filters:- name: RequestRateLimiterargs:redis-rate-limiter.replenishRate: 50  # 稳定速率（每秒50个请求）redis-rate-limiter.burstCapacity: 100 # 突发容量key-resolver: "#{@ipKeyResolver}"     # 按IP限流

        缓存穿透的本质是 “无效请求的无成本穿透”，解决思路核心在于增加无效请求的穿透成本—— 无论是通过缓存空值消耗内存，还是布隆过滤器消耗计算资源，最终目的都是为数据库建立一道 “防护网”。在实际开发中，需结合业务流量特征与系统资源状况，选择最适合的方案。​