Redis 缓存设计与优化

缓存的优缺点及使用场景

好处

1. 加速读写：通过缓存加速读写，如 CPU L1/L2/L3 的缓存、Linux Page Cache 的读写、游览器缓存、Ehchache 缓存数据库结果。
2. 降低后端负载：后端服务器通过前端缓存来降低负载，业务端使用 Redis 来降低后端 MySQL 等数据库的负载。

缺点

1. 数据不一致：这是因为缓存层和数据层有时间窗口是不一致的，这和更新策略有关的。
2. 代码维护成本：这里多了一层缓存逻辑，就会增加成本。
3. 运维费用的成本：如 Redis Cluster，甚至是现在最流行的各种云，都是成本。

 

使用场景

1. 降低后端负载：这是对高消耗的 SQL，join 结果集和分组统计结果缓存。
2. 加速请求响应：这是利用 Redis 或者 Memcache 优化 IO 响应时间。
3. 大量写合并为批量写：比如一些计数器先 Redis 累加以后再批量写入数据库。

缓存的更新策略

三种策略

1. LRU、LFU、FIFO 算法策略。例如 maxmemory-policy，这是最大内存的策略，当 maxmemory 最大时，会优先删除过期数据。我们在控制最大内存，让它帮我们去删除数据。
2. 过期时间剔除，例如 expire。设置过期时间可以保证其性能，如果用户更新了重要信息，应该怎么办。所以这个时候就不适用了。
3. 主动更新，例如开发控制生命周期。

这三个策略中，一致性最好的就是主动更新。能够根据代码实时的更新数据，但是维护成本也是最高的；算法剔除和超时剔除一致性都做的不够好，但是维护成本却非常低。

根据缓存的使用场景，我们会采用不同的更新策略。

实际开发中我给大家以下两个建议。

1. 低一致性：最大内存和淘汰策略，数据库有些数据是不需要马上更新的，这个时候就可以用低一致性来操作。
2. 高一致性：超时剔除和主动更新的结合，最大内存和淘汰策略兜底。你没办法确保内存不会增加，从而使服务不可用了。

缓存粒度问题

我们知道，用户第一次访问客户端，客户端访问 Redis 肯定是没有的，这个时候只能从数据库 DB 那里获取信息，代码如下

select * from t_teacher where id= {id}

在 Redis 设置用户信息缓存，代码如下

set teacher:{id} select * from t_teacher where id= {id}

这个时候我们来看看缓存粒度问题。

因为我们要更新全部属性。到底我们是采用 select * 还是仅仅只是更新你需要更新的那些字段呢？如下两段代码

set key1 = ? from select * from t_teacher

set key1 = ? from select key1 from t_teacher

缓存粒度控制可以从以下三个角度来观察，通过这三点来决定如何选择。

1. 通用性：全量属性更好。上面一个对比 * 和某个字段的查询，最好是通过全量属性，这样的话，select * 具有很好的通用性，因为如果你 select 某个字段的话，未来如果一旦业务改变，代码也要随之改变才可以。
2. 占用空间：部分属性会更好。因为这样占用的空间是最小的。
3. 代码维护上：表面上全量属性会更好。我们真的需要全量吗？其实我们在使用缓存的时候，优先考虑的是内存而不单单只是保证代码的扩展性。

缓存穿透问题

大量请求不命中（即访问缓存拿数据时发现缓存里没有数据，然后再访问数据库拿数据发现还是没有）

              

解决方案1：缓存空对象

当缓存中不存在，访问数据库的时候，又找不到数据，需要设置给 cache 的值为 null，这样下次再次访问该 id 的时候，就会直接访问缓存中的 null 了。

解决方案2：布隆过滤器拦截

布隆过滤器，实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

无底洞问题优化

无底洞问题就是即使加机器，性能却没有提升，反而降低了。到底这是怎么回事呢？先看下面的图。

当客户端增加一个缓存的时候，只需要 mget 一次，但是如果增加到三台缓存，这个时候则需要 mget 三次了，每增加一台，客户端都需要做一次新的 mget，给服务器造成性能上的压力。

同时，mget 需要等待最慢的一台机器操作完成才能算是完成了 mget 操作。这还是并行的设计，如果是串行的设计就更加慢了。

通过上面这个实例可以总结出：更多的机器不等于更高的性能

但是并不是没办法，一般在优化 IO 的时候可以采用以下几个方法。

1. 命令的优化。例如慢查下 keys、hgetall bigkey。
2. 我们需要减少网络通讯的次数。这个优化在实际应用中使用次数是最多的，我们尽量减少通讯次数。
3. 降低接入成本。比如使用客户端长连接或者连接池、NIO 等等。

热点 Key 重建优化

我们知道，使用缓存，如果获取不到，才会去数据库里获取。但是如果是热点 key，访问量非常的大，数据库在重建缓存的时候，会出现很多线程同时重建的情况。

如上图，就是因为高并发导致的大量热点的 key 在重建还没完成的时候，不断被重建缓存的过程，由于大量线程都去做重建缓存工作，导致服务器拖慢的情况。只有最后一个是重建完成，命中缓存。

为了解决以上的问题，我们着重研究了三个目标和两个解决方案。

三个目标为：

• 减少重建缓存的次数；
• 数据尽可能保持一致；
• 减少潜在的风险。

两个解决方案为

• 互斥锁
• 永不过期

我们根据三个目标，解释一下两个解决方案。

 

互斥锁（mutex key）

由下图所示，第一次获取缓存的时候，加一个锁，然后查询数据库，接着是重建缓存。这个时候，另外一个请求又过来获取缓存，发现有个锁，这个时候就去等待，之后都是一次等待的过程，直到重建完成以后，锁解除后再次获取缓存命中。

示例代码：

public String getKey(String key){
    String value = redis.get(key);
    if(value == null){
        String mutexKey = "mutex:key:"+key; //设置互斥锁的key
        if(redis.set(mutexKey,"1","ex 180","nx")){ //给这个key上一把锁，ex表示只有一个线程能执行，过期时间为180秒
          value = db.get(key);
          redis.set(key,value);
          redis.delete(mutexKety);
  }else{
        // 其他的线程休息100毫秒后重试
        Thread.sleep(100);
        getKey(key);
  }
 }
 return value;
}

永远不过期

首先在缓存层面，并没有设置过期时间（过期时间使用 expire 命令）。但是功能层面，我们为每个 value 添加逻辑过期时间，当发现超过逻辑过期时间后，会使用单独的线程去构建缓存。

总结

缓存的收益：加快读写、降低后端存储负载。

缓存的成本：缓存和存储数据不一致性，代码维护成本、运维成本。

更新策略：推荐结合剔除、超时、主动更新三种方案共同完成。

穿透的优化：使用缓存空对象和布隆过滤器来解决，注意各自使用场景和局限性。 

无底洞问题：分布式缓存中，堆积机器不一定会使得性能更好，有四种批量操作方式：串行命令、串行 IO、并行 IO、hash_tag。

雪崩问题：缓存层高可用、客户端降级、提前演练是解决雪崩问题的重要方法。

热点key问题：互斥锁和永不过期这两种方式能够在一定程度上解决热点key问题，但各自有自己的缺点需要我们了解。