《Redis开发与运维》学习笔记--缓存设计

一、缓存的收益和成本

1.1 优点

加速读写；降低后端负载

1.2成本

数据不一致性：缓存层和存储层的数据存在着差异

代码维护成本：同时维护缓存层和存储层的逻辑

运维成本

缓存的使用场景：

开销大的复杂计算：比如MySQL一些复杂的操作或者计算，如果不加缓存，MySQL在并发量大的时候，可能扛不住

加速请求响应

二、缓存的更新策略

2.1 LRU/LFU/FIFO 算法剔除

一般算法剔除是指缓存数目超过了指定的预设值，如何对现有缓存的数据进行剔除。比如最近很少的缓存项，比如最近频繁使用的缓存想，或者先进的先踢出来

2.2 超时剔除

一般是给缓存数据设置过期时间，让其在过期后自动删除。

2.3 主动更新

一般是指对数据一致性要求较高，需要在真实数据更新后，立即更新缓存数据，当然维护成本比较高。

2.4 最佳实践

低一致性业务建议配置最大内存和淘汰策略
高一致性业务建议结合使用超时剔除和主动更新

三、缓存粒度控制

缓存全部属性or部分重要属性？

缓存粒度问题是一个容易被忽视的问题，如果使用不当，可能会造成很多无用空间的浪费，可能会造成网络带宽的浪费，可能会造成代码通用性较差等情况，必须学会综合数据通用性、空间占用比、代码维护性三点评估取舍因素权衡使用。

四、穿透优化

缓存穿透：是指查询一个根本不存在的数据，缓存层和存储层都不会命中，通常我们不会将存储层查不到的数据写入缓存。这将导致这个不存在的数据每次请求都要到存储层去查询，失去了缓存的意义。

例如：下图是一个比较典型的cache-storage架构，cache(例如memcache, redis等等) + storage(例如mysql, hbase等等)架构，查一个压根就不存在的值, 如果不做兼容，永远会查询storage。

缓存穿透的危害：
对底层数据源(mysql, hbase, http接口, rpc调用等等)压力过大，有些底层数据源不具备高并发性。

解决方法：

4.1 缓存空对象

(1) 定义：如上图所示，当第②步MISS后，仍然将空对象保留到Cache中（可能是保留几分钟或者一段时间，具体问题具体分析），下次新的Request（同一个key）将会从Cache中获取到数据，保护了后端的Storage。
(2) 适用场景：数据命中不高，数据频繁变化实时性高（一些乱转业务）
(3) 维护成本：代码比较简单，但是有两个问题：

第一是空值做了缓存，意味着缓存系统中存了更多的key-value，也就是需要更多空间（有人说空值没多少，但是架不住多啊），解决方法是我们可以设置一个较短的过期时间。
第二是数据会有一段时间窗口的不一致，假如，Cache设置了5分钟过期，此时Storage确实有了这个数据的值，那此段时间就会出现数据不一致，解决方法是我们可以利用消息或者其他方式，清除掉Cache中的数据.

(4)伪代码

public class XXXService {  
  
    /** 
     * 缓存 
     */  
   private Cache cache = new Cache();  
  
   /** 
    * 存储 
    */  
   private Storage storage = new Storage();  
  
   /** 
     * 模拟正常模式 
     * @param key 
     * @return 
     */  
   public String getNormal(String key) {  
      // 从缓存中获取数据  
      String cacheValue = cache.get(key);  
      // 缓存为空  
      if (StringUtils.isBlank(cacheValue)) {  
      // 从存储中获取  
      String storageValue = storage.get(key);  
      // 如果存储数据不为空,将存储的值设置到缓存  
      if (StringUtils.isNotBlank(storageValue)) {  
          cache.set(key, storageValue);  
      }  
      return storageValue;  
      } else {  
       // 缓存非空  
        return cacheValue;  
      }  
     }  
  
 
    /** 
    * 模拟防穿透模式 
     * @param key 
     * @return 
     */  
   public String getPassThrough(String key) {  
        // 从缓存中获取数据  
       String cacheValue = cache.get(key);  
        // 缓存为空  
       if (StringUtils.isBlank(cacheValue)) {  
            // 从存储中获取  
           String storageValue = storage.get(key);  
            cache.set(key, storageValue);  
          // 如果存储数据为空，需要设置一个过期时间(300秒)  
            if (StringUtils.isBlank(storageValue)) {  
               cache.expire(key, 60 * 5);  
           }  
           return storageValue;  
       } else {  
           // 缓存非空  
            return cacheValue;  
        }  
   }  
}

4.2 bloomfilter或者压缩filter(bitmap等等)提前拦截

(1)定义：如上图所示，在访问所有资源(cache, storage)之前，将存在的key用布隆过滤器提前保存起来，做第一层拦截, 例如：我们的推荐服务有4亿个用户uid, 我们会根据用户的历史行为进行推荐（非实时），所有的用户推荐数据放到hbase中，但是每天有许多新用户来到网站，这些用户在当天的访问就会穿透到hbase。为此我们每天4点对所有uid做一份布隆过滤器。如果布隆过滤器认为uid不存在，那么就不会访问hbase，在一定程度保护了hbase（减少30%左右）。
(2) 适用场景：数据命中不高，数据相对固定实时性低（通常是数据集较大）
(3) 维护成本：代码维护复杂, 缓存空间占用少

五、无底洞优化

为什么在有的场景，水平添加节点性能不但没有好转反而下降了。这种现象称为缓存的无底洞现象。即更多的节点不代表跟高的性能，投入越多，不一定产出越高。

原因：
一般来说我们加节点，使得集群的性能应该更好，但是为什么性能反而下降了呢？key-value数据库，一般采用哈希函数将key映射到各个节点，造成key的分布和业务无关，但是由于数据量和访问量的持续增长，造成需要添加大量节点做水平扩容，导致key-value分布到更多的节点上，对于Redis批量操作需要从不同节点获取，相比于单机批量操作只涉及一次网络操作，分布式批量操作会涉及到多次网络时间。

无底洞问题分析：

客户端一次批量操作会涉及多次网络操作，就意味着批量操作会随着节点的增多耗时会不断扩大
网络连接数变多，对接点的性能也有一定影响

四种批量优化的方法：

串行mget
我们执行mget，写一个for循环执行每一个get
n次网络时间
优点：编程简单，少量keys满足需求
缺点：大量keys请求延迟严重
串行IO
我在客户端本地做一个内聚，本地有槽和节点的对应关系，就按节点对get进行分组，执行n次pipeline就可以完成对应的mget 。
nodes次网络时间
优点：编程简单，少量节点满足需求
缺点：大量node延迟严重
并行IO
就是多线程进行串行IO
1次网络时间
优点：利用并行特性，延迟取决于最慢的节点
缺点：编程复杂，超时定位问题难
hash_tag
mget(hash_tag)
1次网络时间
优点：性能最高
缺点：读写增加tag的维护成本，tag分布易出现数据倾斜

六、雪崩

指的是缓存层由于某些原因挂了，或者不能提供服务，从而导致流量疯狂的涌入了后端存储层，存储层调用暴涨，造成存储层可能会级联宕机。如下图：

预防和解决雪崩效应的方案：

保证缓存层服务高可用性
依赖隔离组件，为后端限流或者降级

无论是缓存还是存储层都有出错的概率，可以将他们都视作资源。作为并发量较大的系统，假如有一个资源不可用，可能会造成线程全部阻塞，从而系统不可用。

降级机制在高并发系统中非常普遍：比如推荐服务，如果个性化推荐不可用，可以降级补充热点数据。在实际项目中，我们对重要的资源比如Redis，MySQL,HBase或者其他外部接口都进行隔离，每一种资源都单独运行在自己的线程池中，对其他服务没有影响。

七、热点Key重建优化

缓存+过期策略一般情况下，可以加速读写，又保证了数据定期更新，可以满足大部分需求，但是如果有2个问题同时出现，可能造成较大的危害：

当前的key是一个热点key，并发量非常大
重建缓存不可能在短时间内完成，可能是一个复杂的SQL或者多次IO等等。

在缓存失效的瞬间，大量线程来重建缓存，造成后端负载加大，甚至崩溃。

两个解决方案：

互斥锁：重建过程加锁，其他访问获取缓存发现重建过程被锁住了，会进行等待并输出。
优点：思路简单，保证一致性。
缺点：代码复杂度增加，存在死锁风险。
永远不过期：
缓存层面：没有设置过期时间(没有用expire)。
功能层面：为每个value添加逻辑过期时间，一但发现超过逻辑过期时间后，会使用单独的线程去构建缓存。
优点：基本杜绝热点key重建问题。
缺点：不保证一致性，逻辑过期时间增加维护成本和内存成本。

推荐阅读：
缓存那些事