【推荐】缓存的问题及其解决措施探讨-1

蔚落 2022-03-22 15:12 195阅读 0赞

一、缓存更新

一般来说缓存的更新有两种情况:

**先删除缓存，再更新数据库。**

**先更新数据库，再删除缓存。** 这两种情况在业界，大家对其都有自己的看法。具体怎么使用还得看各自的取舍。当然肯定会有人问为什么要删除缓存呢？而不是更新缓存呢？你可以想想当有多个并发的请求更新数据，你并不能保证更新数据库的顺序和更新缓存的顺序一致，那就会出现数据库中和缓存中数据不一致的情况。所以一般来说考虑删除缓存。

**1.1先删除缓存，再更新数据库**

对于一个更新操作简单来说，就是先去各级缓存进行删除，然后更新数据库。**这个操作有一个比较大的问题，在对缓存删除完之后，有一个读请求，这个时候由于缓存被删除所以直接会读库，读操作的数据是老的并且会被加载进入缓存当中，后续读请求全部访问的老数据。**

如何优雅的设计和使用缓存？

对缓存的操作不论成功失败都不能阻塞我们对数据库的操作，那么很多时候删除缓存可以用异步的操作，但是先删除缓存不能很好的适用于这个场景。

**先删除缓存也有一个好处是，如果对数据库操作失败了，那么由于先删除的缓存，最多只是造成Cache Miss。**

**1.2先更新数据库，再删除缓存(推荐)**

如果我们使用更新数据库，再删除缓存就能避免上面的问题。但是同样的引入了新的问题,试想一下有一个数据此时是没有缓存的，所以查询请求会直接落库，更新操作在查询请求之后，但是更新操作删除数据库操作在查询完之后回填缓存之前，就会导致我们缓存中和数据库出现缓存不一致。

为什么我们这种情况有问题，很多公司包括Facebook还会选择呢？因为要触发这个条件比较苛刻。

1、首先需要数据不在缓存中。

2、其次查询操作需要在更新操作先到达数据库。

3、最后查询操作的回填比更新操作的删除后触发，这个条件基本很难出现，因为更新操作的本来在查询操作之后，一般来说更新操作比查询操作稍慢。但是更新操作的删除却在查询操作之后，所以这个情况比较少出现。

对比上面1.1的问题来说这种问题的概率很低，况且我们有超时机制保底所以基本能满足我们的需求。如果真的需要追求完美，可以使用二阶段提交，但是其成本和收益一般来说不成正比。

当然还有个问题是如果我们删除失败了，缓存的数据就会和数据库的数据不一致，那么我们就只能靠过期超时来进行兜底。对此我们可以进行优化，如果删除失败的话 我们不能影响主流程那么我们可以将其放入队列后续进行异步删除。

二、缓存挖坑三剑客

大家一听到缓存有哪些注意事项，肯定首先想到的是缓存穿透，缓存击穿，缓存雪崩这三个挖坑的小能手，这里简单介绍一下他们具体是什么以及应对的方法。

**2.1缓存穿透**

访问一个不存在的key，缓存不起作用，请求会穿透到DB，流量大时DB会挂掉。

为了避免这个问题，可以采取下面两个手段:

1、约定：**对于返回为NULL的依然缓存，对于抛出异常的返回不进行缓存。注意不要把抛异常的也给缓存了。**采用这种手段的会增加我们缓存的维护成本，需要在插入缓存的时候删除这个空缓存，当然我们可以通过设置较短的超时时间来解决这个问题。

![fedfe3f0-73da-315e-a7d6-a4131281c166.jpg][]  
 2. **制定一些规则过滤一些不可能存在的数据**，**小数据用BitMap，大数据可以用布隆过滤器**，比如你的订单ID 明显是在一个范围1-1000，如果不是1-1000之内的数据那其实可以直接给过滤掉。

把所有数据库中不可能存在的数据hash到一张大的bitmap中，如果key在数据库中不存在，将会被bitmap拦截。

![dea4822e-2566-375b-8cda-4ccb289f40ab.jpg][]  
** 2.2缓存击穿**

一个存在的key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增。

为了避免这个问题，我们可以采取下面的两个手段:

**1、加分布式锁：加载数据的时候可以利用分布式锁锁住这个数据的Key，**在Redis中直接使用setNX操作即可，对于获取到这个锁的线程，查询数据库更新缓存，其他线程采取重试策略，这样数据库不会同时受到很多线程访问同一条数据。

集群环境的redis的代码如下所示:

Java代码

String get(String key) {    
       String value = redis.get(key);    
       if (value  == null) {    
            if (redis.setnx(key_mutex, "1")) {    
                // 3 min timeout to avoid mutex holder crash    
                redis.expire(key_mutex, 3 * 60)    
                value = db.get(key);    
                redis.set(key, value);    
                redis.delete(key_mutex);    
            } else {    
                //其他线程休息50毫秒后重试    
                Thread.sleep(50);    
                get(key);    
            }    
      }    
    }

优点:

思路简单

**保证一致性**

缺点

代码复杂度增大

**存在死锁的风险**

**2、异步加载：**由于缓存击穿是热点数据才会出现的问题，可以**对这部分热点数据采取到期自动刷新的策略，而不是到期自动淘汰**。淘汰其实也是为了数据的时效性，所以采用自动刷新也可以。

构建缓存采取异步策略，会从线程池中取线程来异步构建缓存，从而不会让所有的请求直接怼到数据库上。该方案redis自己维护一个timeout，当timeout小于System.currentTimeMillis()时，则进行缓存更新，否则直接返回value值。

集群环境的redis代码如下所示:

Java代码

String get(final String key) {    
            V v = redis.get(key);    
            String value = v.getValue();    
            long timeout = v.getTimeout();    
            if (v.timeout <= System.currentTimeMillis()) {    
      
                // 异步更新后台异常执行    
                threadPool.execute(new Runnable() {    
                    public void run() {    
                        String keyMutex = "mutex:" + key;    
                        if (redis.setnx(keyMutex, "1")) {    
                            // 3 min timeout to avoid mutex holder crash    
                            redis.expire(keyMutex, 3 * 60);    
                            String dbValue = db.get(key);    
                            redis.set(key, dbValue);    
                            redis.delete(keyMutex);    
                        }    
                    }    
                });    
            }    
            return value;    
        }

优点:

性价最佳，**用户无需等待**

**缺点**

**无法保证缓存一致性**

3、**永远不过期**

不设置过期时间。

把**过期时间设到value里，如果快要过期了，通过一个后台异步线程进行缓存的构建**，也就是逻辑过期。

**2.3缓存雪崩**

大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。

为了避免这个问题，我们采取下面的手段:

**1、增加缓存系统可用性**，通过监控关注缓存的健康程度，根据业务量适当的扩容缓存。

**2、采用多级缓存，**不同级别缓存设置的超时时间不同，及时某个级别缓存都过期，也有其他级别缓存兜底。

**3、缓存的过期时间可以取个随机值**，比如以前是设置10分钟的超时时间，那每个Key都可以随机8-13分钟过期，尽量让不同Key的过期时间不同。

三、缓存污染

缓存污染一般出现在我们使用本地缓存中，可以想象，在本地缓存中如果你获得了缓存，但是你接下来修改了这个数据，但是这个数据并没有更新在数据库，这样就造成了缓存污染:

![7efaf30f-db6f-3ba2-a56b-091fb7609efe.jpg][]  
 上面的代码就造成了缓存污染，通过id获取Customer，但是需求需要修改Customer的名字，所以开发人员直接在取出来的对象中直接修改，这个Customer对象就会被污染，其他线程取出这个数据就是错误的数据。要想避免这个问题需要开发人员从编码上注意，并且代码必须经过严格的review，以及全方位的回归测试，才能从一定程度上解决这个问题。

**四、缓存预热**

缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，**缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题**！用户直接查询事先被预热的缓存数据！

解决思路：

1、**直接写个缓存刷新页面，上线时手工操作下；**

2、数据量不大，可以在**项目启动的时候自动进行加载**；

3、**定时刷新缓存**；

**五、缓存降级**

服务降级是**当服务器压力剧增**的情况下，**根据当前业务情况及流量对一些服务和页面有策略的降级**，以此释放服务器资源以保证核心任务的正常运行。降级往往会指定不同的级别，面临不同的异常等级执行不同的处理。

根据服务方式：**可以拒接服务，可以延迟服务**，也有时候可以随机服务。

根据服务范围：**可以砍掉某个功能，也可以砍掉某些模块**。总之服务降级需要根据不同的业务需求采用不同的降级策略。主要的目的就是服务虽然有损但是总比没有好。

**降级的最终目的是保证核心服务可用**，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级。

[fedfe3f0-73da-315e-a7d6-a4131281c166.jpg]: /images/20220322/ee38785f4d6c4b5c88f328d261482d8f.png
[dea4822e-2566-375b-8cda-4ccb289f40ab.jpg]: /images/20220322/c7030253f48b4eecaacdcde73c942e2c.png
[7efaf30f-db6f-3ba2-a56b-091fb7609efe.jpg]: /images/20220322/8fa25b63623748e3bdc4cf77894520f9.png