Redis的雪崩、穿透、热点数据优化

Redis开发与运维节选

[TOC]

一、缓存穿透预防及优化

1、何为穿透

缓存穿透是指查询一个根本不存在的数据，缓存层和存储层都不会命中，但是出于容错的考虑，如果从存储层查不到数据则不写入缓存层

1.缓存层不命中 2.存储层不命中，所以不将空结果写回缓存 3.返回空结果

缓存穿透将导致不存在的数据每次请求都要到存储层去查询，失去了缓存保护后端存储的意义

缓存穿透问题可能会使后端存储负载加大，由于很多后端存储不具备高并发性，甚至可能造成后端存储宕掉。通常可以在程序中分别统计总调用数、缓存层命中数、存储层命中数，如果发现大量存储层空命中，可能就是出现了缓存穿透问题。

造成缓存穿透的基本有两个。第一，业务自身代码或者数据出现问题，第二，一些恶意攻击、爬虫等造成大量空命中，下面我们来看一下如何解决缓存穿透问题。

2、缓存穿透的解决方法

2.1 缓存空对象

如下图所示，当第 2 步存储层不命中后，仍然将空对象保留到缓存层中，之后再访问这个数据将会从缓存中获取，保护了后端数据源。

缓存空对象会有两个问题：第一，空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。

第二，缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5 分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

2、布隆过滤器拦截

二、缓存雪崩问题优化

1、缓存雪崩

从下图可以很清晰出什么是缓存雪崩：由于缓存层承载着大量请求，有效的保护了存储层，但是如果缓存层由于某些原因整体不能提供服务，于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。缓存雪崩的英文原意是 stampeding herd（奔逃的野牛），指的是缓存层宕掉后，流量会像奔逃的野牛一样，打向后端存储。

2、预防和解决缓存雪崩

预防和解决缓存雪崩问题，可以从以下三个方面进行着手。 1）保证缓存层服务高可用性。和飞机都有多个引擎一样，如果缓存层设计成高可用的，即使个别节点、个别机器、甚至是机房宕掉，依然可以提供服务，例如前面介绍过的 Redis Sentinel 和 Redis Cluster 都实现了高可用。

2）依赖隔离组件为后端限流并降级。无论是缓存层还是存储层都会有出错的概率，可以将它们视同为资源。作为并发量较大的系统，假如有一个资源不可用，可能会造成线程全部 hang 在这个资源上，造成整个系统不可用。降级在高并发系统中是非常正常的：比如推荐服务中，如果个性化推荐服务不可用，可以降级补充热点数据，不至于造成前端页面是开天窗。

在实际项目中，我们需要对重要的资源 ( 例如 Redis、 MySQL、 Hbase、外部接口 ) 都进行隔离，让每种资源都单独运行在自己的线程池中，即使个别资源出现了问题，对其他服务没有影响。但是线程池如何管理，比如如何关闭资源池，开启资源池，资源池阀值管理，这些做起来还是相当复杂的，这里推荐一个 Java 依赖隔离工具 Hystrix(https://github.com/Netflix/Hystrix)，如下图所示。

3）提前演练。在项目上线前，演练缓存层宕掉后，应用以及后端的负载情况以及可能出现的问题，在此基础上做一些预案设定。

三、缓存热点 key 重建优化

热点 key 失效后大量线程重建缓存

要解决这个问题也不是很复杂，但是不能为了解决这个问题给系统带来更多的麻烦，所以需要制定如下目标：

减少重建缓存的次数
数据尽可能一致
较少的潜在危险

3.1 互斥锁 (mutex key)

此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可，使用互斥锁重建缓存

String get(String key){
    //从Redis中获取数据
    String value  = redis.get(Key);
    if(value==null){
        //只允许一个线程重建缓存,使用nx,并设置过期时间EX
        String mutexKey = "mutexKey:key"+key;
        if(redis.set(mutexKey,"1","ex 180","nx")){
            //从数据库里获取数据
            value = db.get(key);
            //回写Redis并设置过期时间
            redis.setex(key,timeout,value);
            //删除key_mute
            redis.delete(mutexKey);
        }
        //其他线程休息
        else{
            thread.sleep(50);
            get(key);
        }
    }
    return value;

}

3.2 永远不过期

“永远不过期”包含两层意思：

从缓存层面来看，确实没有设置过期时间，所以不会出现热点 key 过期后产生的问题，也就是“物理”不过期。
从功能层面来看，为每个 value 设置一个逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。

“ 永远不过期 “ 策略

从实战看，此方法有效杜绝了热点 key 产生的问题，但唯一不足的就是重构缓存期间，会出现数据不一致的情况，这取决于应用方是否容忍这种不一致。下面代码使用 Redis 进行模拟：

String get(final String key){
    V v = redis.get(key);
    String value = v.getValue();
    //逻辑过期时间
    if(v.logicTimeout<=System.currentTimeMillis()){
        String mutexKey = "mutex:key"+key;
        if(redis.set(mutexKey,"1","ex 180","nx")){
            //重构缓存
            threadPool.execute(new Runnable(){
                public void run(){
                    String dbValue = db.get(key);
                    redis.set(key,(dbvalue,newLogicTimeOut));
                    redis.delete(mutxKey);
                }
            });
        }
    
    }
    return value;
}

作为一个并发量较大的应用，在使用缓存时有三个目标：第一，加快用户访问速度，提高用户体验。第二，降低后端负载，减少潜在的风险，保证系统平稳。第三，保证数据“尽可能”及时更新。下面将按照这三个维度对上述两种解决方案进行分析。

互斥锁 (mutex key)：这种方案思路比较简单，但是存在一定的隐患，如果构建缓存过程出现问题或者时间较长，可能会存在死锁和线程池阻塞的风险，但是这种方法能够较好的降低后端存储负载并在一致性上做的比较好。
“永远不过期”：这种方案由于没有设置真正的过期时间，实际上已经不存在热点 key 产生的一系列危害，但是会存在数据不一致的情况，同时代码复杂度会增大。

《Redis开发与运维》节选