Redis 缓存设计与优化

本文探讨了Redis缓存的优缺点、使用场景及更新策略。提到了LRU、LFU、FIFO等更新策略,并针对缓存粒度、缓存穿透、无底洞问题及热点Key的重建优化提出了解决方案。强调了缓存一致性、空间占用和代码维护的平衡,以及利用互斥锁和永不过期策略处理热点Key问题的重要性。
摘要由CSDN通过智能技术生成

缓存的优缺点及使用场景

好处

  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问题,但各自有自己的缺点需要我们了解。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值