深度剖析缓存相关问题：雪崩、穿透、预热、更新、降级

缓存雪崩是指在缓存中的大量数据同时过期或失效，导致大量请求直接落到数据库，压力剧增，可能导致系统崩溃。我们可以简单的理解为：由于原有缓存失效，新缓存未到期间 (例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

1.2 解决方案

1.2.1 加锁防止并发重建缓存

public class CacheService {

    private final Object lock = new Object();

    public Object getData(String key) {
        Object data = getFromCache(key);
        if (data == null) {
            synchronized (lock) {
                data = getFromCache(key);
                if (data == null) {
                    data = getFromDatabase(key);
                    putIntoCache(key, data);
                }
            }
        }
        return data;
    }
    
    // 其他业务逻辑...
}

2. 缓存穿透

2.1 问题描述

缓存穿透是指用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

2.2 解决方案

2.2.1 布隆过滤器防止无效请求

public class CacheService {

    private final BloomFilter<String> bloomFilter = new BloomFilter<>();

    public Object getData(String key) {
        if (!bloomFilter.mightContain(key)) {
            return null;
        }

        Object data = getFromCache(key);
        if (data == null) {
            data = getFromDatabase(key);
            putIntoCache(key, data);
        }
        return data;
    }
    
    // 其他业务逻辑...
}

3. 缓存预热

3.1 问题描述

缓存预热是指在系统上线或重启后，将部分或全部数据预先加载到缓存中，防止大量请求直接访问数据库。

3.2 分析与解决方案

3.2.1 定时任务预热缓存

通过定时任务，在系统启动或每天凌晨1点等时机，将需要预热的数据加载到缓存中：

@Component
public class CacheWarmUpTask {

    @Autowired
    private CacheService cacheService;

    @Scheduled(cron = "0 0 1 * * ?") // 每天凌晨1点执行
    public void warmUpCache() {
        List<String> keysToWarmUp = getKeysToWarmUp();
        for (String key : keysToWarmUp) {
            cacheService.getData(key);
        }
    }
    
    private List<String> getKeysToWarmUp() {
        // 根据业务逻辑获取需要预热的缓存键列表
        // ...
    }
}

4. 缓存更新

4.1 问题描述

缓存更新是指数据库中的数据更新后，及时将缓存中的数据进行同步。

4.2 分析与解决方案

4.2.1 主动更新缓存

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：（1）定时去清理过期的缓存；（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

public class CacheService {

    public void updateCache(String key, Object newData) {
        // 更新缓存
        putIntoCache(key, newData);
    }
    
    // 其他业务逻辑...
}

5. 缓存降级

5.1 问题描述

缓存降级是指在系统遇到异常或缓存失效的情况下，通过某种方式提供默认值或兜底数据，保证系统正常运行。

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。降级的最终目的是保证核心服务可用，即使是有损的而且有些服务是无法降级的（如加入购物车、结算）。以参考日志级别设置预案：（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。服务降级的目的，是为了防止Redis服务故障，导致数据库跟着一起发生雪崩问题。因此，对于不重要的缓存数据，可以采取服务降级策略，例如一个比较常见的做法就是Redis出现问题，不去数据库查询，而是直接返回默认值给用户。

5.2 分析与解决方案

5.2.1 降级机制提供默认值

在缓存失效或异常时，提供默认值或兜底数据，确保系统正常运行：

public class CacheService {

    public Object getData(String key) {
        Object data = getFromCache(key);
        if (data == null) {
            data = getFromDatabase(key);
            if (data != null) {
                putIntoCache(key, data);
            } else {
                data = getDefaultData();
            }
        }
        return data;
    }

    private Object getDefaultData() {
        // 提供默认值或兜底数据
        // ...
    }
    
    // 其他业务逻辑...
}

总结

通过深入分析缓存雪崩、缓存穿透、缓存预热、缓存更新、缓存降级等问题，并提供相应的解决方案，可以有效提高系统的稳定性和性能。在实际应用中，应根据业务场景选择合适的方案，综合考虑多方面因素，以保障系统的高可用性和稳定性。长文分析力求全面，希望能为读者提供深度的理解和实践指导。

祝屏幕前的你，好运不断！

原文地址:https://blog.csdn.net/2201_75809246/article/details/135536914

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。

如若转载，请注明出处：http://www.7code.cn/show_55214.html

如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！

声明：本站所有文章，如无特殊说明或标注，均为本站原创发布。任何个人或组织，在未征得本站同意时，禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益，可联系我们进行处理。

缓存解决方案预热

引言

1. 缓存雪崩

1.1 问题描述