缓存：热点key重建优化。

Love The Way You Lie 2022-02-01 13:25 189阅读 0赞

开发人员使用”缓存+过期时间“的策略既可以加速数据读写，又保证数据的定时更新，这种模式基本满足绝大部分需求。但是有两个问题如果同时出现，可能就会对应用造成致命的危害：

*  当前key是一个热点key（例如一个热门的娱乐新闻），并发量非常大。
 *  重建缓存不能在短时间完成，可能是一个复杂计算，例如复杂的SQL、多次IO、多个依赖等。

在缓存失效的瞬间，有大量线程来重建缓存（如下图所示），造成后端负载加大，甚至可能会让应用奔溃。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70][]

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

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

# 互斥锁（mutex key） #

此方法只允许一个线程重建缓存，其他线程等待重建缓存的线程执行完，重新从缓存获取数据即可，整个过程如下图所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 1][]

下面代码使用Redis的setnx命令实现上述功能：

String get(String key) {
        // 从Redis中获取数据
        String value = redis.get(key);
        // 如果value为空，则开始重构缓存
        if(value == null) {
            // 只允许一个线程重构缓存，使用nx，并设置过期时间ex
            String mutexKey = "mutext:key:" + key;
            if(redis.set(mutexKey, "1", "ex 180", "nx")) {
                // 从数据源获取数据
                value = db.get(key);
                // 回写Redis,并设置过期时间
                redis.setex(key, timeout, value);
                // 删除key_mutex
                redis.delete(mutex_key);
            }
            // 其他线程休息50毫秒后重试
            else {
                Thread.sleep(50);
                get(key);
            }
        }
        return value;
    }

*  从Redis获取数据，如果值不为空，则直接返回值；否则执行下面2和3步骤。
 *  如果set(nx和ex)结果为true，说明此时没有其他线程重建缓存，那么当前线程执行缓存构建逻辑。
 *  如果set(nx和ex)结果为false，说明此时已经有其他线程正在执行构建缓存的工作，那么当前线程将休息指定时间（例如这里是50毫秒，取决于构建缓存的速度）后，重新执行函数，直到获取到数据。

# 永远不过期 #

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

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

整个过程如下图所示。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 2][]

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

String get(final String key) {
        V v = redis.get(key);
        String value = v.getValue();
        // 逻辑过期时间
        long logicTimeout = v.getLogicTimeout();
        // 如果逻辑过期时间小于当前时间，开始后台构建
        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(mutexKey);
                    }
                });
            }
        }
        return value;
    }

作为一个并发量较大的应用，在使用缓存时有三个目标：

*  加快用户访问速度，提高用户体验。
 *  降低后端负载，减少潜在的风险，保证系统平稳。
 *  保证数据“尽可能”及时更新。

下面将按照这三个维度对上述两种解决方案进行分析。

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

两种解决方法对比如下表所示。

<table style="width:698px;"> 
 <thead> 
  <tr> 
   <th>解决方案</th> 
   <th>优点</th> 
   <th>缺点</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>简单分布式锁</td> 
   <td> <p>思路简单</p> <p>保证一致性</p> </td> 
   <td> <p>代码复杂度增大</p> <p>存在死锁的风险</p> <p>存在线程池阻塞的风险</p> </td> 
  </tr> 
  <tr> 
   <td>永远不过期</td> 
   <td>基本杜绝热点key问题</td> 
   <td> <p>不保证一致性</p> <p>逻辑过期时间增加代码维护成本和内存成本</p> </td> 
  </tr> 
 </tbody> 
</table>

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70]: /images/20220201/95de71ee446b47febf9ecabefd10f9d1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 1]: /images/20220201/dbe194fd1aec484fa8313b77cbe20006.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2VuX2pva2Vy_size_16_color_FFFFFF_t_70 2]: /images/20220201/5397aaa08316443b883cf4912c6445e2.png