如何更有效的使用 Redis 缓存

前言

对于 Redis 来讲,作为缓存使用,是我们在业务中经常使用的,这里总结下,Redis 作为缓存在业务中的使用。

旁路缓存

Cache Aside(旁路缓存)策略以数据库中的数据为准,缓存中的数据是按需加载的。它可以分为读策略和写策略。

只读缓存

只读缓存 从缓存中读取数据;如果缓存命中,则直接返回数据;如果缓存不命中,则从数据库中查询数据;查询到数据后,将数据写入到缓存中,并且返回给用户。

如果需要对数据进行修改的时候,直接修改数据库中的数据,然后删除缓存中的旧数据。

只读缓存的优点:

所有最新的数据都在数据库中,数据不存在丢失的风险。

缺点:

每次修改数据,都会删除缓冲,之后的请求会发生一次缓存缺失。

读写缓存

除了进行读操作外,数据的修改操作也会发送到缓存中,直接在缓存中对数据进行修改。此时,得益于Redis的高性能访问特性,数据的增删改操作可以在缓存中快速完成,处理结果也会快速返回给业务应用,这就可以提升业务应用的响应速度。

当然 Redis 是内存数据库,一旦掉电或宕机,内存中的数据就有可能存在丢失。

针对这种情况,一般会有两种回写策略:

  • 1、同步回写;

写请求发给缓存的同时,也会发给后端数据库进行处理,等到缓存和数据库都写完数据,才给客户端返回。这样,即使缓存宕机或发生故障,最新的数据仍然保存在数据库中,这就提供了数据可靠性保证。

不过,同步直写会降低缓存的访问性能。这是因为缓存中处理写请求的速度是很快的,而数据库处理写请求的速度较慢。即使缓存很快地处理了写请求,也需要等待数据库处理完所有的写请求,才能给应用返回结果,这就增加了缓存的响应延迟。

  • 2、异步回写。

所有写请求都先在缓存中处理。可以定时将缓存写入到内存中,然后等到这些增改的数据要被从缓存中淘汰出来时,再次将它们写回后端数据库。这样一来,处理这些数据的操作是在缓存中进行的,很快就能完成。只不过,如果发生了掉电,而它们还没有被写回数据库,就会有丢失的风险了。

优点:

被修改的数据永远在缓存中,不会发生缓存缺失,下次可以直接访问,不在需要向数据库中进行一次查询。

缺点:

数据可能存在丢失的风险。

设置多大的缓存合适

缓存能够提高响应速度,但是缓存的数量也不是越多越好?

1、大容量缓存是能带来性能加速的收益,但是成本也会更高;

2、在一些场景中,比如秒杀,少量的缓存承担的就是绝大部分的流量访问。

系统的设计选择是一个权衡的过程:大容量缓存是能带来性能加速的收益,但是成本也会更高,而小容量缓存不一定就起不到加速访问的效果。一般来说,建议把缓存容量设置为总数据量的15%到30%,兼顾访问性能和内存空间开销。

内存被写满了如何处理

Redis 中的内存被写满了,就会触发内存淘汰机制了

具体参加内存淘汰机制

缓存经常遇到的问题

Redis 作为缓存,经常遇到的几种情况:缓存中的数据和数据库中的不一致;缓存雪崩;缓存击穿和缓存穿透。

下面一一来探讨下

1、缓存中的数据和数据库中的不一致

数据一致性,通俗的理解就是,数据库中的数据和缓冲中的数据完全一致就满足一致性。不过对于只读缓存,如果缓冲中没有就去数据库中查询,这样如果缓存中没有数据,但是数据库中的数据是最新的,最终也能满足数据一致性。

所以总结下,一致性大致分成下面的两种情况:

1、缓存中有数据,缓存中的数据和数据库中的数据一样;

2、缓存中没有数据,数据库中记录了最新的数据。

下面分析下只读缓存和读写缓存中的数据不一致情况

读写缓存

读写缓存有同步写回和异步写回两种策略

同步写回:缓存在新增修改的时候,也会同步数据到数据库中,这样总能保持缓存中的数据和数据库中的一致;

异步写回:缓存新增修改时候,先不写回到数据库中,定时或者缓存中数据淘汰的时候,再写回到数据库中。这种,如果 Redis 故障宕机了,没有及时写回数据到数据库中,就会造成数据的不一致。

对于读写缓存,使用同步写回的策略,能保证数据数据的一致性。不过,需要在业务应用中使用事务机制,来保证缓存和数据库的更新具有原子性,也就是说,两者要不一起更新,要不都不更新,返回错误信息,进行重试。否则,我们就无法实现同步直写。

如果系统没宕机,redis 系统正常的情况下,因为读写缓存,缓存中的数据是一直存在的,所以当修改数据的时候先修改缓存中的数据,这样就算并发很大的情况下,因为缓存中的数据都是最新的,并且一直存在,这样数据总能读取到最新的数据。

只读缓存

只读缓存,如果数据新增,直接写入到数据库中,如果有数据修改删除,也是直接操作数据库不过缓存中的数据不会更新,而是直接删除缓存中的数据。

这样数据的更新操作之后,数据库中的数据总是最新的,缓存中就会发生缓存缺失,此时就会从数据库中读取数据,然后再加载到缓存中,这样缓存中的数据总能和数据库中的数据一致。

只读缓存在数据新增的时候,缓存中是没有数据的,所以肯定是要从数据库中加载,这种情况不存在数据不一致的情况。

在只读缓存中,数据不一致的情况,发生在数据的更新删除操作中,下面来一一分析下

删改操作既要修改数据库,同时还要删除对应的缓存,如果这两个操作的原子性无法得到保证,(一起操作成功,或者一起操作失败),那么数据的一致性就得不到保证了。

来个异常的栗子

1、先修改数据库,然后删除缓存,但是删除缓存失败了;

删除缓存失败了,那么缓存中存在的就是旧值,这时候用户的请求过来了,首先去缓存中查询,这时候拿到的就是老旧的数据。

2、先删除缓存,在修改数据库,修改数据库失败了;

缓存删除成功,数据库修改失败了,那么数据库中存在的就是旧值,因为缓存已经被删除了,这时候去缓存中查询,发生了缓存的缺失,数据就会从数据库中加载到缓存中,这时候读取到也是老旧的数据。

C++后台开发系统学习地址:C/C++Linux服务器开发高级架构师/C++后台开发架构师​

以下学习资料,C++后台开发面试题,教学视频,C++后台开发学习路线图,免费分享有需要的可以自行添加:学习资料群720209036 自取

如何更有效的使用 Redis 缓存_第1张图片

​针对这种问题如何解决呢?

上面出现异常的两种场景,归根到底,就是两者操作的原子性没有得到保证,所以可以借助于消息队列实现最终的一致性。

使用 mq 解决分布式事务可参见分布式事务

这里的操作场景相对简单一点,只要借助于 mq 的重试机制,保证第二步的操成功就可以了。

栗如:

1、先修改数据库;

2、发送删除缓存的消息到 mq 中;

3、下游收到删除的消息,操作删除缓存,如果失败,借助于 mq 的重试机制,就能进行重试操作,直到成功。当然如果,重试多次还是失败,我们需要记录错误原因,然后通知业务方。

如何更有效的使用 Redis 缓存_第2张图片

​那到底应该先删除缓存还是先修改数据库呢?这里我们再探讨一下

1、先删除缓存后修改数据库

先删除缓存,然后修改数据库

如果数据库的更新有延迟,那么这时候一个线程过来查询该数据,因为缓存中已经删除了,这时候发生了缓存的缺失,然后就回去数据库中查询,数据库可能还没有更新成功,就可能获取到旧值。

如何解决呢

使用 延迟双删 策略

当数据库被修改之后,线程 sleep 一段时间,然后再次删除缓存,然缓存发生一次缺失,这样下次的请求,就能把数据库中最新的数据加载到缓存中。

如何更有效的使用 Redis 缓存_第3张图片

​比如上面的这种情况,因为数据库的更新可能存在延迟,所以时候线程2读取到了数据库的旧值,然后加载到了缓存中,这样接下来的所有的查询就都会读取旧值

所以 线程1,通过延迟双删来处理这种情况

线程1,在 sleep 一段时间之后,删除缓存,这样就能使后续的缓存缺失,后续的查询就能加载数据库中最新的数据到缓存中。

不过 sleep 的时间需要大于,线程2,读数据并且写入数据到内存的时间,如果 sleep 时间过小,这时候线程2,的旧值还没有写入到缓存中,线程1,已经再次删除了缓存,然后这时候线程2把旧值写入,导致缓存中依然是旧数据。

redis.delKey(X)
db.update(X)
Thread.sleep(N)
redis.delKey(X)

当然,这在 sleep 的时间内,还是有一部分请求会读取到旧值

2、先修改数据库然后删除缓存

先修改数据库,然后删除缓存

如果缓存删除有延迟,那么这时候过来的请求,就会读取到缓存中老旧的数据,不过缓存会马上被删除,只会有少部分的数据读取到老旧的数据,对业务影响比较小。

经过对比,发现先修改数据库然后在删除缓存,对我们业务的影响比较小,同时也跟容易处理。

只读缓存和读写缓存如何选择

读写缓存对比只读缓存

优点:缓存中一直会有数据,如果更新操作后会立即再次访问,可以直接命中缓存,能够降低读请求对于数据库的压力。

缺点:如果更新后的数据,之后很少再被访问到,会导致缓存中保留的不是最热的数据,缓存利用率不高(只读缓存中保留的都是热数据)。

所以读写缓存比较适合用于读写相当的业务场景。

2、缓存雪崩

什么是缓存雪崩

缓存雪崩是指大量的应用请求无法在Redis缓存中进行处理,紧接着,应用将大量请求发送到数据库层,导致数据库层的压力激增。

缓存雪崩有两种场景

1、大量缓存同时过期

如果有大量的缓存 key 设置了同样的过期时间,如果这些缓存 key 过期了,同时有大量的请求,进来了,这些请求就会直接打到数据库中,数据库可能因为这些请求,导致数据库压力增大,严重的时候数据库宕机。

如何解决呢?

1、避免给大量的过期键设置相同的过期时间,设计过期时间的时候,可以考虑加入一个业务上允许的过期随机值;

2、服务降级,只有部分核心业务的请求,才会流转到数据库中,数据库的压力就会被大大减轻了;

  • 当业务应用访问的是非核心数据(例如电商商品属性)时,暂时停止从缓存中查询这些数据,而是直接返回预定义信息、空值或是错误信息;

  • 当业务应用访问的是核心数据(例如电商商品库存)时,仍然允许查询缓存,如果缓存缺失,也可以继续通过数据库读取。

2、Redis 实例发生宕机

Redis 实例的宕机,缓存层就不能处理数据,最总流量都会流入到数据库中

如何解决呢?

1、业务中实现服务熔断或者请求限流机制;

  • 服务熔断:如果监听到发生了缓存雪崩,直接暂停对缓存服务的请求,但是这种对业务的影响比较大;

  • 服务限流:可以在入口做限流,不要让所有的请求都流入到后端的服务中;

2、提前预防,搭建 Redis 的高可用集群;

  • 尝试构建 Redis 的高可用集群,比如当某主节点挂掉了,集群能够马上重新选出新的主节点。例如哨兵机制

3、缓存击穿

其实跟缓存雪崩有点类似,缓存雪崩是大规模的key失效,而缓存击穿是一个热点的Key,有大并发集中对其进行访问,突然间这个Key失效了,导致大并发全部打在数据库上,导致数据库压力剧增。这种现象就叫做缓存击穿。

如何解决?

对于热点 key 可以不设置过期时间,或者设置一个超过使用周期的过期时间,保证这个 key 在业务使用期间永远存在。

4、缓存穿透

如果业务请求的缓存,既不在缓存中,也不再数据库中,那么缓存将没有用,所有的请求都会流入到数据库中。

那么,缓存穿透会发生在什么时候呢?一般来说,有两种情况。

1、业务层误操作:缓存中的数据和数据库中的数据被误删除了,所以缓存和数据库中都没有数据;

2、恶意攻击:专门访问数据库中没有的数据。

如何解决?

1、缓存空值或缺省值;

一旦发生缓存穿透,在缓存中写入一个业务中允许的空值,这样缓存中有数据了,就避免了缓存穿透。

2、使用布隆过滤器;

使用布隆过滤器判断下数据是否存在,数据如果不存在,就不向数据库发起请求了。

布隆过滤器

3、在请求入口的前端进行请求检测;

缓存穿透的一个原因是有大量的恶意请求访问不存在的数据,所以,一个有效的应对方案是在请求入口前端,对业务系统接收到的请求进行合法性检测,把恶意的请求(例如请求参数不合理、请求参数是非法值、请求字段不存在)直接过滤掉,不让它们访问后端缓存和数据库。这样一来,也就不会出现缓存穿透问题了。

缓存中的 hot key 和 big key

这两种的处理方式可参见

Hot Key 和 big key

总结

对于缓存的使用,我们经常用到的有两种1、只读缓存;2、读写缓存;

只读缓存,对比读写缓存

优点:缓存中一直会有数据,如果更新操作后会立即再次访问,可以直接命中缓存,能够降低读请求对于数据库的压力。

缺点:如果更新后的数据,之后很少再被访问到,会导致缓存中保留的不是最热的数据,缓存利用率不高(只读缓存中保留的都是热数据)。

所以读写缓存比较适合用于读写相当的业务场景。

缓存在使用的过程中,会面临缓存中的数据和数据库中的不一致;缓存雪崩;缓存击穿和缓存穿透,这些我们需要弄明白这些情况发生的额场景,然后再业务中一一去避免。

参考资料

推荐一个零声教育C/C++后台开发的免费公开课程,个人觉得老师讲得不错,分享给大家:C/C++后台开发高级架构师,内容包括Linux,Nginx,ZeroMQ,MySQL,Redis,fastdfs,MongoDB,ZK,流媒体,CDN,P2P,K8S,Docker,TCP/IP,协程,DPDK等技术内容,立即学习

你可能感兴趣的:(Linux服务器开发,Linux后台开发,redis,Redis,Redis,缓存,中间件,后端开发,C++后台开发)