Redis旁路缓存深度解析

为什么需要缓存

在互联网应用里，数据库往往是整个系统的性能瓶颈。想象一下，当海量并发读取请求瞬间涌来时，如果每次都直接去敲数据库的门，会发生什么？

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

结果通常不太美妙：数据库连接池被迅速榨干，复杂查询带来的响应延迟动辄几十甚至几百毫秒，用户体验直线下降。更棘手的是，想通过简单增加数据库实例来扩容，成本高昂且收效未必显著。

这时候，缓存的价值就凸显出来了。它的思路很直接：把那些被频繁访问的“热点”数据，提前搬到内存里。内存的访问速度是微秒级的，相比磁盘I/O，这简直是降维打击。

旁路缓存核心原理

在众多缓存应用模式中，旁路缓存（Cache-Aside Pattern）堪称经典中的经典。它的核心哲学非常清晰：由应用程序主动管理缓存，数据库是绝对的数据源头，缓存只是它的一个高效“副本”。

读操作流程

public Product getProduct(Long id) {
    // 1. 先查缓存
    Product cachedProduct = redis.get("product:" + id);
    if (cachedProduct != null) {
        // 缓存命中，直接返回
        return cachedProduct;
    }
    // 2. 缓存未命中，查询数据库
    Product product = productMapper.findById(id);
    if (product != null) {
        // 3. 将数据写入缓存，设置过期时间
        redis.set("product:" + id, product, 3600);
    }
    return product;
}

读操作的逻辑链条非常直观：

1. 第一步，先去Redis里看看有没有。
2. 如果有（缓存命中），皆大欢喜，直接返回。
3. 如果没有（缓存未命中），那就只能老老实实去查数据库。
4. 从数据库拿到数据后，别忘了“回填”到缓存里，并给它设置一个合理的过期时间，方便后续请求快速获取。

写操作流程

public void updateProduct(Product product) {
    // 1. 先更新数据库
    productMapper.update(product);
    // 2. 再删除缓存
    redis.del("product:" + product.getId());
}

写操作采用了先更新数据库，再删除缓存的策略。为什么是“删除”而不是“更新”缓存？这里面有几个关键的考量：

• 保证数据最终一致性：即使缓存删除这一步失败了，数据库里的数据也已经是最新的。下次读取时，缓存未命中会触发数据库查询，并将新数据重新加载到缓存中，最终达到一致。
• 规避并发难题：在并发写场景下，更新缓存的时序很难控制，容易导致缓存与数据库数据不一致。直接删除缓存则简单粗暴且有效。
• 简化系统复杂度：不需要去维护一套缓存与数据库之间强同步的复杂机制。

缓存三大经典问题

1. 缓存穿透

问题描述：查询一个根本不存在的数据。因为缓存和数据库里都没有，所以每次请求都会穿透缓存，直接打到数据库上。

危害：这可不是小问题。如果被恶意攻击者利用，持续用大量不存在的数据ID发起请求，数据库很可能被压垮。

解决方案：

public Product getProduct(Long id) {
    // 参数校验
    if (id == null || id <= 0) {
        return null;
    }
    // 1. 先查缓存
    Product cachedProduct = redis.get("product:" + id);
    if (cachedProduct != null) {
        return cachedProduct;
    }
    // 2. 缓存未命中，查询数据库
    Product product = productMapper.findById(id);
    if (product == null) {
        // 3. 缓存空值，防止穿透
        redis.set("product:" + id, null, 60); // 短过期时间
        return null;
    }
    // 4. 写入缓存
    redis.set("product:" + id, product, 3600);
    return product;
}

额外防护措施：对于穿透风险极高的场景，可以引入布隆过滤器（Bloom Filter）作为前置屏障。

// 使用布隆过滤器
private BloomFilter bloomFilter;

public Product getProduct(Long id) {
    // 布隆过滤器检查
    if (!bloomFilter.mightContain(id)) {
        return null; // 一定不存在
    }
    // 正常查询流程
    Product product = getProductFromCacheOrDB(id);
    return product;
}

2. 缓存击穿

问题描述：注意，这和“穿透”不同。击穿指的是某个热点Key在缓存过期的瞬间，大量并发请求同时发现缓存失效，于是这些请求像洪水一样全部涌向数据库。

解决方案：

方案一：互斥锁

private boolean lock = false;
public Product getProduct(Long id) {
    Product product = redis.get("product:" + id);
    if (product != null) {
        return product;
    }
    // 获取锁
    if (tryLock("lock:product:" + id)) {
        try {
            // Double Check
            product = redis.get("product:" + id);
            if (product != null) {
                return product;
            }
            // 查询数据库
            product = productMapper.findById(id);
            redis.set("product:" + id, product, 3600);
        } finally {
            unlock("lock:product:" + id);
        }
    } else {
        // 等待后重试
        Thread.sleep(100);
        return getProduct(id);
    }
    return product;
}

方案二：逻辑过期

public Product getProduct(Long id) {
    // 1. 查缓存
    Product product = redis.get("product:" + id);
    if (product == null) {
        // 缓存为空，尝试获取锁重建缓存
        if (tryLock("lock:product:" + id)) {
            Product newProduct = productMapper.findById(id);
            redis.set("product:" + id, newProduct, 3600);
            unlock("lock:product:" + id);
            return newProduct;
        }
        // 等待后重试
        Thread.sleep(100);
        return getProduct(id);
    }
    // 2. 检查是否逻辑过期
    if (isLogicalExpired(product)) {
        // 异步重建缓存，不阻塞请求
        if (tryLock("lock:product:" + id)) {
            threadPool.execute(() -> {
                Product newProduct = productMapper.findById(id);
                redis.set("product:" + id, newProduct, 3600);
                unlock("lock:product:" + id);
            });
        }
    }
    return product;
}

3. 缓存雪崩

问题描述：大量缓存数据在同一时间过期失效，导致所有请求在那一刻都去查询数据库，数据库压力瞬间激增，可能引发连锁故障。

解决方案：

方案一：随机过期时间

// 设置过期时间添加随机值
int baseExpire = 3600;
int randomExpire = ThreadLocalRandom.current().nextInt(300);
redis.set("product:" + id, product, baseExpire + randomExpire);

方案二：多级缓存

public Product getProduct(Long id) {
    // 1. 先查本地缓存
    Product product = localCache.get(id);
    if (product != null) {
        return product;
    }
    // 2. 查 Redis
    product = redis.get("product:" + id);
    if (product != null) {
        // 回填本地缓存
        localCache.put(id, product, 300);
        return product;
    }
    // 3. 查数据库
    product = productMapper.findById(id);
    redis.set("product:" + id, product, 3600);
    return product;
}

方案三：服务降级

public Product getProduct(Long id) {
    try {
        // 1. 查缓存
        Product product = redis.get("product:" + id);
        if (product != null) {
            return product;
        }
        // 2. 缓存未命中，降级处理
        return getProductFromBackup(id);
    } catch (Exception e) {
        // Redis 异常，降级到数据库
        log.error("Redis error, fallback to DB", e);
        return productMapper.findById(id);
    }
}

数据一致性方案

延迟双删

public void updateProduct(Product product) {
    // 1. 删除缓存
    redis.del("product:" + product.getId());
    // 2. 更新数据库
    productMapper.update(product);
    // 3. 延迟删除缓存
    threadPool.execute(() -> {
        try {
            Thread.sleep(1000);
            redis.del("product:" + product.getId());
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    });
}

延迟双删策略主要用在写操作非常频繁，且对数据一致性要求极高的场景。第二次延迟删除，是为了清理掉在“更新数据库”这个极短时间窗口内，可能被其他线程读请求重新写入缓存的旧数据。

订阅 Binlog + Canal

// Canal 配置
@CanalMessageListener(topic = "product_db.product")
public void onMessage(CanalEntry.Entry entry) {
    CanalEntry.RowChange rowChange = CanalEntry.RowChange.parseFrom(entry.getStoreValue());
    for (CanalEntry.RowData rowData : rowChange.getRowDatasList()) {
        if (rowChange.getEventType() == CanalEntry.EventType.UPDATE) {
            // 更新操作
            for (Column column : rowData.getBeforeColumnsList()) {
                if ("id".equals(column.getName())) {
                    Long id = Long.parseLong(column.getValue());
                    redis.del("product:" + id);
                }
            }
        }
    }
}

优势：

• 完全解耦：缓存更新异步化，完全不干扰主业务逻辑。
• 保证最终一致性：基于数据库的Binlog，能可靠地捕获所有数据变更。
• 适合大型系统：在复杂的分布式架构中，这种方案的可维护性和扩展性更好。

缓存策略最佳实践

缓存 key 设计

// 好的设计
String key = "product:info:" + categoryId + ":" + productId;
String key = "user:profile:" + userId;
String key = "order:summary:" + dateStr;

// 避免的设计
String key = "product_" + productId;           // 缺少命名空间，易冲突
String key = getComplexKey(product);            // 包含复杂计算，影响性能
String key = "temp:" + System.currentTimeMillis(); // 使用时效性数据，难以管理

缓存 Value 设计

// 序列化配置
@Cacheable(value = "products", key = "#id", unless = "#result == null")
public Product getProduct(Long id) {
    return productMapper.findById(id);
}

// JSON 序列化
@Configuration
public class RedisConfig {
    @Bean
    public RedisTemplate redisTemplate(RedisConnectionFactory factory) {
        RedisTemplate template = new RedisTemplate<>();
        template.setConnectionFactory(factory);
        Jackson2JsonRedisSerializer