Redis缓存:淘汰机制、缓存雪崩、数据不一致,都一步说到位

在实际的工作项目中, 缓存成为高并发、高性能架构的关键组件 ,那么Redis为什么可以作为缓存使用呢?首先可以作为缓存的两个主要特征:

  • 在分层系统中处于内存/CPU具有访问性能良好,
  • 缓存数据饱和,有良好的数据淘汰机制

由于Redis 天然就具有这两个特征,Redis基于内存操作的,且其具有完善的数据淘汰机制,十分适合作为缓存组件。

其中,基于内存操作,容量可以为32-96GB,且操作时间平均为100ns,操作效率高。而且数据淘汰机制众多,在Redis 4.0 后就有8种了促使Redis作为缓存可以适用很多场景。

那Redis缓存为什么需要数据淘汰机制呢?有哪8种数据淘汰机制呢?

数据淘汰机制

Redis缓存基于内存实现的,则其缓存其容量是有限的,当出现缓存被写满的情况,那么这时Redis该如何处理呢?

Redis对于缓存被写满的情况,Redis就需要缓存数据淘汰机制,通过一定淘汰规则将一些数据刷选出来删除,让缓存服务可再使用。那么Redis使用哪些淘汰策略进行刷选删除数据?

在Redis 4.0 之后,Redis 缓存淘汰策略6+2种,包括分成三大类:

  • 不淘汰数据

    • noeviction ,不进行数据淘汰,当缓存被写满后,Redis不提供服务直接返回错误。
  • 在设置过期时间的键值对中,

    • volatile-random ,在设置过期时间的键值对中随机删除
    • volatile-ttl ,在设置过期时间的键值对,基于过期时间的先后进行删除,越早过期的越先被删除。
    • volatile-lru , 基于LRU(Least Recently Used) 算法筛选设置了过期时间的键值对, 最近最少使用的原则来筛选数据
    • volatile-lfu ,使用 LFU( Least Frequently Used ) 算法选择设置了过期时间的键值对,使用频率最少的键值对,来筛选数据。
  • 在所有的键值对中,

    • allkeys-random, 从所有键值对中随机选择并删除数据
    • allkeys-lru, 使用 LRU 算法在所有数据中进行筛选
    • allkeys-lfu, 使用 LFU 算法在所有数据中进行筛选

 

Note: LRU( 最近最少使用,Least Recently Used)算法, LRU维护一个双向链表 ,链表的头和尾分别表示 MRU 端和 LRU 端,分别代表最近最常使用的数据和最近最不常用的数据。

LRU 算法在实际实现时,需要用链表管理所有的缓存数据,这会带来额外的空间开销。而且,当有数据被访问时,需要在链表上把该数据移动到 MRU 端,如果有大量数据被访问,就会带来很多链表移动操作,会很耗时,进而会降低 Redis 缓存性能。

其中,LRU和LFU 基于Redis的对象结构redisObject的lru和refcount属性实现的:

typedef struct redisObject {
    unsigned type:4;
    unsigned encoding:4;
    // 对象最后一次被访问的时间
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
    // 引用计数                        * and most significant 16 bits access time). */
    int refcount;
    void *ptr;
} robj;

Redis的LRU会使用redisObject的lru记录最近一次被访问的时间,随机选取参数maxmemory-samples 配置的数量作为候选集合,在其中选择 lru 属性值最小的数据淘汰出去。

在实际项目中,那么该如何选择数据淘汰机制呢?

  • 优先选择 allkeys-lru算法,将最近最常访问的数据留在缓存中,提升应用的访问性能。
  • 有顶置数据使用 volatile-lru算法,顶置数据不设置缓存过期时间,其他数据设置过期时间,基于LRU 规则进行筛选 。

在理解了Redis缓存淘汰机制后,来看看Redis作为缓存其有多少种模式呢?

Redis缓存模式

Redis缓存模式基于是否接收写请求,可以分成只读缓存和读写缓存:

只读缓存:只处理读操作,所有的更新操作都在数据库中,这样数据不会有丢失的风险。

  • Cache Aside模式

 

读写缓存,读写操作都在缓存中执行,出现宕机故障,会导致数据丢失。缓存回写数据到数据库有分成两种同步和异步:

  • 同步:访问性能偏低,其更加侧重于保证数据可靠性

    • Read-Throug模式
    • Write-Through模式
  • 异步:有数据丢失风险,其侧重于提供低延迟访问

    • Write-Behind模式

 

Cache Aside模式

查询数据先从缓存读取数据,如果缓存中不存在,则再到数据库中读取数据,获取到数据之后更新到缓存Cache中,但更新数据操作,会先去更新数据库种的数据,然后将缓存种的数据失效。

而且Cache Aside模式会存在并发风险:执行读操作未命中缓存,然后查询数据库中取数据,数据已经查询到还没放入缓存,同时一个更新写操作让缓存失效,然后读操作再把查询到数据加载缓存,导致缓存的脏数据。

Read/Write-Throug模式

查询数据和更新数据都直接访问缓存服务,缓存服务同步方式地将数据更新到数据库。出现脏数据的概率较低,但是就强依赖缓存,对缓存服务的稳定性有较大要求,但同步更新会导致其性能不好。

Write Behind模式

查询数据和更新数据都直接访问缓存服务,但缓存服务使用异步方式地将数据更新到数据库(通过异步任务) 速度快,效率会非常高,但是数据的一致性比较差,还可能会有数据的丢失情况,实现逻辑也较为复杂。

在实际项目开发中根据实际的业务场景需求来进行选择缓存模式。那了解上述后,我们的应用中为什么需要使用到redis缓存呢?

在应用使用Redis缓存可以提高系统性能和并发,主要体现在

  • 高性能:基于内存查询,KV结构,简单逻辑运算
  • 高并发: Mysql 每秒只能支持2000左右的请求,Redis轻松每秒1W以上。让80%以上查询走缓存,20%以下查询走数据库,能让系统吞吐量有很大的提高

虽然使用Redis缓存可以大大提升系统的性能,但是使用了缓存,会出现一些问题,比如,缓存与数据库双向不一致、缓存雪崩等,对于出现的这些问题该怎么解决呢?

使用缓存常见的问题

使用了缓存,会出现一些问题,主要体现在:

  • 缓存与数据库双写不一致
  • 缓存雪崩: Redis 缓存无法处理大量的应用请求,转移到数据库层导致数据库层的压力激增;
  • 缓存穿透:访问数据不存在在Redis缓存中和数据库中,导致大量访问穿透缓存直接转移到数据库导致数据库层的压力激增;
  • 缓存击穿:缓存无法处理高频热点数据,导致直接高频访问数据库导致数据库层的压力激增;

缓存与数据库数据不一致

只读缓存(Cache Aside模式)

对于只读缓存(Cache Aside模式), 读操作都发生在缓存中,数据不一致只会发生在删改操作上(新增操作不会,因为新增只会在数据库处理),当发生删改操作时,缓存将数据中标志为无效和更新数据库 。因此在更新数据库和删除缓存值的过程中,无论这两个操作的执行顺序谁先谁后,只要有一个操作失败了就会出现数据不一致的情况。

总结出,当不存在并发的情况使用重试机制(消息队列使用),当存在高并发的情况,使用延迟双删除(在第一次删除后,睡眠一定时间后,再进行删除),具体如下:

操作顺序 是否高并发 潜在问题 现象 应对方案
先删除缓存,再更新数据库 缓存删除成功,数据库更新失败 读到数据库的旧值 重试机制(数据库更新)
先更新数据库,再删除缓存 数据库更新成功,缓存删除失败 读到缓存的旧值 重试机制(缓存删除)
先删除缓存,再更新数据库 缓存删除后,尚未更新数据库,有并发读请求 并发读请求读到数据库旧值,并更新到缓存,导致之后的读请求读到旧值 延迟双删()
先更新数据库,再删除缓存 数据库更新成功,尚未删除缓存 读到缓存的旧值 不一致的情况短暂存在,对业务影响较小

NOTE:

延迟双删除伪代码:

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

读写缓存(Read/Write-Throug、Write Behind模式 )

对于读写缓存,写操作都发生在缓存中,后再更新数据库,只要有一个操作失败了就会出现数据不一致的情况。

总结出,当不存在并发的情况使用重试机制(消息队列使用),当存在高并发的情况,使用分布锁。具体如下:

操作顺序 是否高 并发 潜在问题 现象 应对方案
先更新缓存,再更新数据库 缓存更新成功,数据库更新失败 会从缓存中读到最新值,短期影响不大 重试机制(数据库更新)
先更新数据库,再更新缓存 数据库更新成功,缓存更新失败 会从缓存读到旧值 重试机制(缓存删除)
先更新数据库,再更新缓存 写+读并发 线程A先更新数据库,之后线程B读取数据,之后线程A更新缓存 B会命中缓存,读取到旧值 A更新缓存前,对业务有短暂影响
先更新缓存,再更新数据库 写+读并发 线程A先更新缓存成功,之后线程B读取数据,此时线程B命中缓存,读取到最新值后返回,之后线程A更新数据库成功 B会命中缓存,读取到最新值 业务没影响
先更新数据库,再更新缓存 写+写并发 线程A和线程B同时更新同一条数据,更新数据库的顺序是先A后B,但更新缓存时顺序是先B后A,这会导致数据库和缓存的不一致 数据库和缓存的不一致 写操作加分布式锁
先更新缓存,再更新数据库 写+写并发 线程A和线程B同时更新同一条数据,更新缓存的顺序是先A后B,但是更新数据库的顺序是先B后A,这也会导致数据库和缓存的不一致 数据库和缓存的不一致 写操作加分布式锁

缓存雪崩

缓存雪崩,由于缓存中有大量数据同时过期失效或者缓存出现宕机,大量的应用请求无法在 Redis 缓存中进行处理,进而发送到数据库层导致数据库层的压力激增,严重的会造成数据库宕机。

对于缓存中有大量数据同时过期,导致大量请求无法得到处理, 解决方式:

  • 数据预热将发生大并发访问前手动触发加载缓存不同的key, 可以避免在用户请求的时候,先查询数据库
  • 设置不同的过期时间,让缓存失效的时间点尽量均匀
  • 双层缓存策略, 在原始缓存上加上拷贝缓存,原始缓存失效时可以访问拷贝缓存,且原始缓存失效时间设置为短期,拷贝缓存设置为长期
  • 服务降级 , 发生缓存雪崩时,针对不同的数据采取不同的降级方案 ,比如,非核心数据直接返回预定义信息、空值或是错误信息

对于缓存出现宕机,解决方式:

  • 业务系统中实现服务熔断或请求限流机制,防止大量访问导致数据库出现宕机

缓存穿透

缓存穿透,数据在数据库和缓存中都不存在,这样就导致查询数据,在缓存中找不到对应key的value,都要去数据库再查询一遍,然后返回空(相当于进行了两次无用的查询)。

当有大量访问请求,且其绕过缓存直接查数据库,导致数据库层的压力激增,严重的会造成数据库宕机。

对于缓存穿透,解决方式:

  • 缓存空值或缺省值,当一个查询返回的数据为空时, 空结果也将进行缓存,并将它的过期时间设置比较短,下次访问直接从缓存中取值,避免了把大量请求发送给数据库处理,造成数据库出问题。
  • 布隆过滤器( BloomFilter ),将所有可能查询数据key哈希到一个足够大的bitmap中,在查询的时候先去BloomFilter去查询key是否存在,如果不存在就直接返回,存在再去查询缓存,缓存中没有再去查询数据库 ,从而避免了数据库层的压力激增出现宕机。

缓存击穿

缓存击穿,针对某个访问非常频繁的热点数据过期失效,导致访问无法在缓存中进行处理,进而会有导致大量的直接请求数据库,从而使得数据库层的压力激增,严重的会造成数据库宕机。

对于缓存击穿,解决方式:

  • 不设置过期时间,对于访问特别频繁的热点数据,不设置过期时间。

总结

在大多数业务场景下,Redis缓存作为只读缓存使用。针对只读缓存来说, 优先使用先更新数据库再删除缓存的方法保证数据一致性 。

其中,缓存雪崩,缓存穿透,缓存击穿三大问题的原因和解决方式

 

 

原文地址:https://blog.csdn.net/thlzjfefe" target="_blank" rel="noopener" title="thlzjfefe">thlzjfefe</a> <img class="article-time-img article-heard-img" src="https://csdnimg.cn/release/blo

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


文章浏览阅读1.3k次。在 Redis 中,键(Keys)是非常重要的概念,它们代表了存储在数据库中的数据的标识符。对键的有效管理和操作是使用 Redis 数据库的关键一环,它直接影响到数据的存取效率、系统的稳定性和开发的便利性。本文将深入探讨 Redis 中键的管理和操作,包括键的命名规范、常用的键操作命令以及一些最佳实践。我们将详细介绍如何合理命名键、如何使用键的过期和持久化特性、如何批量删除键等技巧,旨在帮助读者更好地理解并灵活运用 Redis 中的键,从而提高数据管理和操作的效率和可靠性。
文章浏览阅读3.3k次,点赞44次,收藏88次。本篇是对单节点的应用,但从中我们也能推断出一些关于集群的应用,不过大多数公司能搞个主从就已经是不错了,所以你能学会这个已经算是很有用了,关于ES,博主前面也讲过一些基础应用,创建一个工具类利用ES的数据模型进行存储就可以达到一个canal同时对Redis和ES的同步,如果担心出问题,可以把Canal搞成集群的形式,这个后续有时间博主再给大家做讲解。今天就到这里了,觉得不错就支持一下吧。_canal redis
文章浏览阅读8.4k次,点赞8次,收藏18次。Spring Boot 整合Redis实现消息队列,RedisMessageListenerContainer的使用,Pub/Sub模式的优缺点_springboot redis 消息队列
文章浏览阅读978次,点赞25次,收藏21次。在Centos上安装Redis5.0保姆级教程!_centos7 安装redis5.0服务器
文章浏览阅读1.2k次,点赞21次,收藏22次。Docker-Compose部署Redis(v7.2)主从模式首先需要有一个redis主从集群,才能接着做redis哨兵模式。_warning: sentinel was not able to save the new configuration on disk!!!: dev
文章浏览阅读2.2k次,点赞59次,收藏38次。合理的JedisPool资源池参数设置能为业务使用Redis保驾护航,本文将对JedisPool的使用、资源池的参数进行详细说明,最后给出“最合理”配置。_jedispool资源池优化
文章浏览阅读1.9k次。批量删除指定前缀的Key有两中方法,一种是借助 redis-cli,另一种是通过 SCAN命令来遍历所有匹配前缀的 key,并使用 DEL命令逐个删除它们。_redis删除前缀的key
文章浏览阅读890次,点赞18次,收藏20次。1. Redis时一个key-cakye的数据库,key一般是String类型,不过value类型有很多。eg.String Hash List Set SortedSet (基本) | GEO BitMap HyperLog (特殊)2.Redis为了方便学习,将操作不同类型的命令做了分组,在官网可以进行查询。
文章浏览阅读1.1k次,点赞19次,收藏26次。若不使用Redisson,而是用synchronized(this),此时会造成对服务器的加锁,若开始大量查询ID为1的商品,每台机器都会先跑一遍加个锁,然后在查询ID为2的数据,此时需要等待ID为1的锁释放,所以需要将this对象调整为全局商品ID。若在执行bgsave命令时,还有其他redis命令被执行(主线程数据修改),此时会对数据做个副本,然后bgsave命令执行这个副本数据写入rdb文件,此时主线程还可以继续修改数据。在当前redis目录下会生成aof文件,对redis修改数据的命令进行备份。
文章浏览阅读1.5k次,点赞39次,收藏24次。本文全面剖析Redis集群在分布式环境下的数据一致性问题,从基础原理到高级特性,涵盖主从复制、哨兵模式、持久化策略等关键点,同时也分享了关于监控、故障模拟与自适应写一致性策略的实践经验。_redis集群一致性
文章浏览阅读1k次。RDB因为是二进制文件,在保存的时候体积也是比较小的,它恢复的比较快,但是它有可能会丢数据,我们通常在项目中也会使用AOF来恢复数据,虽然AOF恢复的速度慢一些,但是它丢数据的风险要小很多,在AOF文件中可以设置刷盘策略,我们当时设置的就是每秒批量写入一次命令。AOF的含义是追加文件,当redis操作写命令的时候,都会存储这个文件中,当redis实例宕机恢复数据的时候,会从这个文件中再次执行一遍命令来恢复数据。:在Redis中提供了两种数据持久化的方式:1、RDB 2、AOF。
文章浏览阅读1k次,点赞24次,收藏21次。NoSQL(No only SQL)数据库,泛指非关系型数据库,实现对于传统数据库而言的。NoSQL 不依赖业务逻辑方式进行存储,而以简单的 key-value 模式存储。因此大大增加了数据库的扩展能力。不遵循SQL标准不支持ACID远超于SQL的性能Redis是当前比较热门的NOSQL系统之一,它是一个开源的使用ANSI c语言编写的key-value存储系统(区别于MySQL的二维表格的形式存储。
文章浏览阅读988次,点赞17次,收藏19次。在上面的步骤中,我们已经开启了 MySQL 的远程访问功能,但是,如果使用 MySQL 管理工具 navicat 连接 MySQL 服务端时,还是可能会出现连接失败的情况。在实际工作中,如果我们需要从其他地方访问和管理 MySQL 数据库,就需要开启 MySQL 的远程访问功能并设置相应的权限。这对于我们的工作效率和数据安全都有很大的帮助。通过查看 MySQL 用户表,我们可以看到’host’为’%’,说明 root 用户登录 MySQL 的时候,可以允许任意的 IP 地址访问 MySQL 服务端。
文章浏览阅读956次。Redis Desktop Manager(RDM)是一款用于管理和操作Redis数据库的图形化界面工具。提供了简单易用的界面,使用户能够方便地执行各种Redis数据库操作,并且支持多个Redis服务器的连接_redisdesktopmanager安装包
文章浏览阅读1.9k次,点赞52次,收藏27次。缓存击穿指的是数据库有数据,缓存本应该也有数据,但是缓存过期了,Redis 这层流量防护屏障被击穿了,请求直奔数据库。缓存穿透指的是数据库本就没有这个数据,请求直奔数据库,缓存系统形同虚设。缓存雪崩指的是大量的热点数据无法在 Redis 缓存中处理(大面积热点数据缓存失效、Redis 宕机),流量全部打到数据库,导致数据库极大压力。
文章浏览阅读1.2k次。一次命令时间(borrow|return resource + Jedis执行命令(含网络) )的平均耗时约为1ms,一个连接的QPS大约是1000,业务期望的QPS是50000,那么理论上需要的资源池大小是50000 / 1000 = 50个,实际maxTotal可以根据理论值合理进行微调。JedisPool默认的maxTotal=8,下面的代码从JedisPool中借了8次Jedis,但是没有归还,当第9次(jedisPool.getResource().ping())3、发生异常可能的情况。_redis.clients.jedis.exceptions.jedisconnectionexception: could not get a res
文章浏览阅读1k次,点赞27次,收藏18次。在这篇文章中,你将了解到如何在 CentOS 系统上安装 Redis 服务,并且掌握通过自定义域名来访问 Redis 服务的技巧。通过使用自定义域名,你可以方便地管理和访问你的 Redis 数据库,提高工作效率。无论你是开发者、系统管理员还是对 Redis 感兴趣的读者,这篇文章都会为你提供清晰的指导和实用的技巧。阅读本文,轻松搭建自己的 Redis 服务,并体验自定义域名带来的便捷!_redis怎么自定义域名
文章浏览阅读1.1k次,点赞15次,收藏18次。我们post请求,拦截器要预先读取HtppServletRequest里面的body的数据,是通过io的方式,都知道io读取完毕之后,之前的数据是变为null的,但是,当我么后面的接口来委派的时候,也是通过io读取body。我们要考虑一个事情,就是我们要验证数据的重复提交: 首先第一次提交的数据肯定是要被存储的,当而第二次往后,每次提交数据都会与之前的数据产生比对从而验证数据重复提交,我们要具体判断数据是否重复提交的子类。发现数据是成功存入的,剩余7s过期,在10s之内,也就是数据没过期之前,在发送一次。_json.parseobject(str, clazz, auto_type_filter);
文章浏览阅读3.9k次,点赞3次,收藏7次。PHP使用Redis实战实录系列:我们首先检查$redis->connect()方法的返回值来确定是否成功连接到Redis服务器。如果连接失败,我们可以输出相应的错误信息。如果连接成功,我们再执行一些操作,如$redis->set()、$redis->get()等,并检查每个操作的返回结果来判断是否发生了异常。_php redis
文章浏览阅读1.5w次,点赞23次,收藏51次。Redis(Remote Dictionary Server ),即远程字典服务,是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。Redis 是一个高性能的key-value数据库。redis的出现,很大程度补偿了memcached这类key/value存储的不足,在部 分场合可以对关系数据库起到很好的补充作用。_redisdesktopmanager下载