Hi,大家好,我是编程小6,很荣幸遇见你,我把这些年在开发过程中遇到的问题或想法写出来,今天说一说redis缓存雪崩和缓存击穿_Redis缓存雪崩及其解决方案,希望能够帮助你!!!。
2022年《进大厂系列》11道Redis常见面试题(带答案)
大家好,我是小于哥,今天分享一个关于Java面试Redis相关的面试题,如果你只是会用Redis,只会增删改查,,那么你基本上面试要挂的,昨天竟然有知友被问倒了~~
Redis与Memcached的区别
如何保证缓存与数据库双写时的数据一致性?
Redis常见性能问题和解决方案?
Redis官方为什么不提供Windows版本?
一个字符串类型的值能存储最大容量是多少?
Redis如何做大量数据插入?
假如Redis里面有1亿个key,其中有10w个key是以某个固定的已知的前缀开头的,如果将它们全部找出来?
使用Redis做过
异步队列吗,是如何实现的
Redis如何实现延时队列
Redis回收进程如何工作的?
Redis回收使用的是什么算法?
什么是Redis缓存雪崩、缓存穿透和缓存击穿?
Redis是一种支持key-value等多种数据结构的存储系统。可用于缓存,事件发布或订阅,高速队列等场景。支持网络,提供字符串,哈希,列表,队列,集合结构直接存取,基于内存,可持久化。
Redis:读的速度是110000次/s,写的速度是81000次/s
Redis支持Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
支持事务,操作都是原子性,所谓的原子性就是对数据的更改要么全部执行,要么全部不执行
Redis支持简易订阅通知(Pub/Sub) ,按key设置过期时间,过期后将会自动删除。
Redis支持RDB, AOF等持久化方式
单线程的原因:
Redis快的原因:
1、redis完全基于内存:绝大部分请求是纯粹的内存操作,非常快速。
2、数据结构简单:redis中的数据结构是专门进行设计的。
3、采用单线程模型,避免了不必要的上下文切换和竞争条件:也不存在多线程或者多线程切换而消耗CPU, 不用考虑各种锁的问题, 不存在加锁, 释放锁的操作, 没有因为可能出现死锁而导致性能消耗
4、使用了多路IO复用模型:非阻塞IO
缓存是Redis最常见的应用场景,主要是因为Redis读写性能优异。而且逐渐有取代memcached,成为首选服务端缓存的组件。而且,Redis内部是支持事务的,在使用时候能有效保证数据的一致性。
redis中可以使用expire命令设置一个键的生存时间,到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景。
redis由于incrby命令可以实现原子性的递增,所以可以运用于高并发的秒杀活动、分布式序列号的生成、具体业务还体现在比如限制一个手机号发多少条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。
这个主要利用redis的setnx命令进行,setnx:"set if not exists"就是如果不存在则成功设置缓存同时返回1,否则返回0 。因为我们服务器是集群的,定时任务可能在两台机器上都会运行,所以在定时任务中首先 通过setnx设置一个lock,如果成功设置则执行,如果没有成功设置,则表明该定时任务已执行。 当然结合具体业务,我们可以给这个lock加一个过期时间,比如说30分钟执行一次的定时任务,那么这个过期时间设置为小于30分钟的一个时间就可以,这个与定时任务的周期以及定时任务执行消耗时间相关。
expire:设置key的过期时间
persist:设置key永久有效
String(字符串):
底层数据结构:
SDS即动态字符串,最大容量512M,每次最多扩容1M,是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或序列化的对象
应用场景:分布式锁、计数器(如访问次数、点赞转发数量)
常用方法:set 、get、strlen 、incr 、 decr 、setnx、setex、exists
list(双向列表):
特点:单值多键,用来存储多个有序的字符串,一个列表最多可以存储2^32-1个元素。可以实现队列和栈
底层数据结构:
快表
应用场景:消息队列 、文章列表
常用方法:lpush 、lrang 、rpush 、lpop 、rpop 、llen、lindex、rpoplpush、linsert
Hash(哈希):
底层数据结构:
压缩列表、
哈希表。
特点:指v(值)本身又是一个键值对(k-v)结构
应用场景:缓存用户信息、购物车等。
常用方法:hset 、hget 、hkeys 、hvals 、hmset 、hmget 、hgetAll 、hlen 、hdel 、hsetnx 、hexists
set(集合):
特点:用来保存多个的字符串元素,但是不允许重复元素,元素是无序的。可以实现并集、交集、差集的操作
底层数据结构:
哈希表、
整数集
应用场景:抽奖、共同、sigusoft内推等。
常用方法:sadd 、smembers 、sismember 、scard 、srem 、srandmember、spop、smove、sdiff、sinter、sunion
zset(有序集合):
特点:有序不重复的集合。和 set 相⽐sorted set 增加了⼀个权重参数 score,可以根据score进行排序,但score是可以重复的,value是不可以重复的。
底层数据结构:
压缩列表、
跳表
应用场景:排行榜、抖音热搜
常用方法:zadd 、zrange 、zrangebyscore(按score从小到大) 、zrem 、zcard 、zcount 、zrevrange(按score从大到小)
补充一下:Redis相关的面试题,可以去收藏一下之前总结的这个文章:
实现一个排版榜,我们通常想到的就是mysql的order by 简单粗暴就撸出来了。但是这样真的优雅吗?
数据库是系统的瓶颈,这是众所周知的。如果给你一张百万的表,让你排序做排行榜,花费的时间是十分可怕的。
不如缓存吧,order by的时候强制使用索引。但是这样真的优雅吗?
终端研发部:Redis面试五连问,2021年跳槽必备!
是Redis默认的持久化方式。按照一定的时间将内存的数据以快照的形式保存到硬盘中,对应产生的数据文件为dump.rdb。通过配置文件中的save参数来定义快照的周期。
触发方式:触发rdb持久化的方式有2种,分别是手动触发和自动触发。
手动触发:
自动触发:
save m n
,即在m秒内有n次修改时,自动触发bgsave生成rdb文件;优点:
缺点:
数据安全性低。RDB 是间隔一段时间进行持久化,如果持久化之间 redis 发生故障,会发生数据丢失。所以这种方式更适合数据要求不严谨的时候
将Redis执行的每次写命令记录到单独的日志文件中,当重启Redis会重新将持久化的日志中文件恢复数据。AOF日志是一种写后日志,“写后”的意思是Redis是先执行命令,把数据写入内存,然后才记录日志
为什么采用写后日志?
但这种方式存在潜在风险:
AOF的实现:
AOF日志记录Redis的每个写命令,步骤分为:命令追加、文件的写入和同步。
AOF的重写 :
Redis通过创建一个新的AOF文件来替换现有的AOF,新旧两个AOF文件保存的数据相同,但新AOF文件没有了冗余命令。
AOF重写会阻塞吗?
AOF重写过程是由后台进程bgrewriteaof来完成的。主线程fork出后台的bgrewriteaof子进程,fork会把主线程的内存拷贝一份给bgrewriteaof子进程,这里面就包含了数据库的最新数据。然后,bgrewriteaof子进程就可以在不影响主线程的情况下,逐一把拷贝的数据写成操作,记入重写日志。
所以aof在重写时,在fork进程时是会阻塞住主线程的。
AOF日志何时会重写?
有两个配置项控制AOF重写的触发:
auto-aof-rewrite-min-size:
表示运行AOF重写时文件的最小大小,默认为64MB。
auto-aof-rewrite-percentage:
这个值的计算方式是,当前aof文件大小和上一次重写后aof文件大小的差值,再除以上一次重写后aof文件大小。也就是当前aof文件比上一次重写后aof文件的增量大小,和上一次重写后aof文件大小的比值。
优点:
缺点:
Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令,一个事务中所有命令都会被序列化。在事务执行过程,会按照顺序串行化执行队列中的命令,其他客户端提交的命令请求不会插入到事务执行命令序列中。
总结说:redis事务就是一次性、顺序性、排他性的执行一个队列中的一系列命令。
Redis官方文档给的理解是,
Redis的事务是原子性的:所有的命令,要么全部执行,要么全部不执行。而不是完全成功。
redis事务可以保证命令失败的情况下得以回滚,数据能恢复到没有执行之前的样子,是保证一致性的,除非redis进程意外终结。
redis事务是严格遵守隔离性的,原因是redis是单进程单线程模式(v6.0之前),可以保证命令执行过程中不会被其他客户端命令打断。但是,Redis不像其它结构化数据库有隔离级别这种设计。
redis事务是不保证持久性的,这是因为redis持久化策略中不管是RDB还是AOF都是异步执行的,不保证持久性是出于对性能的考虑。
每一次请求不同的值(符合有效的值规则),并且该值是数据库不可能存在的。那么就会出现不停的访问数据库,并返回空。这样就使 redis 无效化,便是缓存穿透。
当发生缓存雪崩或击穿时,数据库中还是保存了应用要访问的数据,一旦缓存恢复相对应的数据,就可以减轻数据库的压力,而缓存穿透就不一样了。
当用户访问的
数据既
不在缓存中,也不在数据库中,导致请求在访问缓存时,发现缓存缺失,再去访问数据库时,发现数据库中也没有要访问的数据,没办法构建缓存数据,来服务后续的请求。那么当
短时间内有大量这样的请求到来时,数据库的压力骤增,这就是
缓存穿透的问题。
缓存穿透的发生一般有这两种情况:
应对缓存穿透的方案,常见的方案有三种。
1、非法请求的限制;
当有大量恶意请求访问不存在的数据的时候,也会发生缓存穿透,因此在 API 入口处我们要判断求请求参数是否合理,请求参数是否含有非法值、请求字段是否存在,如果判断出是恶意请求就直接返回错误,避免进一步访问缓存和数据库。
2、缓存空值或者默认值;
当我们线上业务发现缓存穿透的现象时,可以针对查询的数据,在缓存中设置一个空值或者默认值,这样后续请求就可以从缓存中读取到空值或者默认值,返回给应用,而不会继续查询数据库。
3、使用布隆过滤器快速判断数据是否存在,避免通过查询数据库来判断数据是否存在;
布隆过滤器的本质:
布隆过滤器实现思想:
业务通常会有几个数据会被频繁地访问,比如秒杀活动,这类被频地访问的数据被称为
热点数据【当前key是一个热点key】
如果缓存中的
某个热点数据过期了,此时
大量的请求访问了该热点数据,就无法从缓存中读取,重建缓存不能在短时间完成,可能是一个复杂计算,例如复杂的SQL、多次IO、多个依赖等。
直接访问数据库,在缓存失效的瞬间,有大量线程来重建缓存,造成后端负载加大,数据库很容易就被高并发的请求冲垮,这就是
缓存击穿的问题
1、互斥锁方案
保证同一时间只允许一个线程重建缓存,未能互斥锁的请求,要么等待锁释放后重新读取缓存,要么就返回空值或者默认值【set(key,value,timeout)】。
2、永不过期
不给热点数据设置过期时间,由后台异步更新缓存,或者在热点数据准备要过期前,提前通知后台线程更新缓存以及重新设置过期时间
总结对比:
分布式互斥锁:这种方案思路比较简单,但是存在一定的隐患,如果在查询数据库 + 和 重建缓存(key失效后进行了大量的计算)时间过长,也可能会存在死锁和线程池阻塞的风险,高并发情景下吞吐量会大大降低!但是这种方法能够较好地降低后端存储负载,并在一致性上做得比较好。
永远不过期:这种方案由于没有设置真正的过期时间,实际上已经不存在热点key产生的一系列危害,但是会存在数据不一致的情况,同时代码复杂度会增大。
通常我们为了保证缓存中的数据与数据库中的数据一致性,会给 Redis 里的数据设置过期时间,当缓存数据过期后,用户访问的数据如果不在缓存里,业务系统需要重新生成缓存,因此就会访问数据库,并将数据更新到 Redis 里,这样后续请求都可以直接命中缓存。
那么,当
大量缓存数据在同一时间过期(失效)或者 Redis 故障宕机时,如果此时有大量的用户请求,都无法在 Redis 中处理,于是
全部请求都直接访问数据库,从而
导致数据库的压力骤增,严重的会造成数据库宕机,从而形成一系列连锁反应,造成整个系统崩溃,这就是
缓存雪崩的问题。
和缓存击穿不同的是,缓存击穿指并发查同一条数据,缓存雪崩是不同数据都过期了,很多数据都查不到从而查数据库。
1、大量数据同时过期
针对大量数据同时过期而引发的缓存雪崩问题,常见的应对方法有下面这几种:
1. 均匀设置过期时间
如果要给缓存数据设置过期时间,应该避免将大量的数据设置成同一个过期时间。我们可以在对缓存数据设置过期时间时,给这些数据的过期时间加上一个随机数,这样就保证数据不会在同一时间过期。
2. 互斥锁
当业务线程在处理用户请求时,如果发现访问的数据不在 Redis 里,就加个互斥锁,保证同一时间内只有一个请求来构建缓存(从数据库读取数据,再将数据更新到 Redis 里),当缓存构建完成后,再释放锁。未能互斥锁的请求,要么等待锁释放后重新读取缓存,要么就返回空值或者默认值。
实现互斥锁的时候,最好设置超时时间,不然第一个请求拿到了锁,然后这个请求发生了某种意外而一直阻塞,一直不释放锁,这时其他请求也一直拿不到锁,整个系统就会出现无响应的现象。
3. 双 key 策略
我们对缓存数据可以使用两个 key,一个是主 key,会设置过期时间,一个是备 key,不会设置过期,它们只是 key 不一样,但是 value 值是一样的,相当于给缓存数据做了个副本。
当业务线程访问不到「主 key 」的缓存数据时,就直接返回「备 key 」的缓存数据,然后在更新缓存的时候,同时更新「主 key 」和「备 key 」的数据。
4. 后台更新缓存
业务线程不再负责更新缓存,缓存也不设置有效期,而是让缓存“永久有效”,并将更新缓存的工作交由后台线程定时更新。
事实上,缓存数据不设置有效期,并不是意味着数据一直能在内存里,因为当系统内存紧张的时候,有些缓存数据会被“淘汰”,而在缓存被“淘汰”到下一次后台定时更新缓存的这段时间内,业务线程读取缓存失败就返回空值,业务的视角就以为是数据丢失了。
解决上面的问题的方式有两种。
第一种方式,后台线程不仅负责定时更新缓存,而且也负责频繁地检测缓存是否有效,检测到缓存失效了,原因可能是系统紧张而被淘汰的,于是就要马上从数据库读取数据,并更新到缓存。
这种方式的检测时间间隔不能太长,太长也导致用户的数据是一个空值而不是真正的数据,所以检测的间隔最好是毫秒级的,但是总归是有个间隔时间,用户体验一般。
第二种方式,在业务线程发现缓存数据失效后(缓存数据被淘汰),通过消息队列发送一条消息通知后台线程更新缓存,后台线程收到消息后,在更新缓存前可以判断缓存是否存在,存在就不执行更新缓存操作;不存在就读取数据库数据,并将数据加载到缓存。这种方式相比第一种方式缓存的更新会更及时,用户体验也比较好。
在业务刚上线的时候,我们最好提前把数据缓起来,而不是等待用户访问才来触发缓存构建,这就是所谓的缓存预热,后台更新缓存的机制刚好也适合干这个事情。
针对 Redis 故障宕机而引发的缓存雪崩问题,常见的应对方法有下面这几种:
1. 服务熔断或请求限流机制
因为 Redis 故障宕机而导致缓存雪崩问题时,我们可以启动服务熔断机制,暂停业务应用对缓存服务的访问,直接返回错误,不用再继续访问数据库,从而降低对数据库的访问压力,保证数据库系统的正常运行,然后等到 Redis 恢复正常后,再允许业务应用访问缓存服务。
服务熔断机制是保护数据库的正常允许,但是暂停了业务应用访问缓存服系统,全部业务都无法正常工作
为了减少对业务的影响,我们可以启用请求限流机制,只将少部分请求发送到数据库进行处理,再多的请求就在入口直接拒绝服务,等到 Redis 恢复正常并把缓存预热完后,再解除请求限流的机制。
2. 构建 Redis 缓存高可靠集群
服务熔断或请求限流机制是缓存雪崩发生后的应对方案,我们最好通过主从节点的方式构建 Redis 缓存高可靠集群。
如果 Redis 缓存的主节点故障宕机,从节点可以切换成为主节点,继续提供缓存服务,避免了由于 Redis 故障宕机而导致的缓存雪崩问题。
主从复制,是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(master),后者称为从节点(slave);数据的复制是单向的,只能由主节点到从节点。
作用:
主从库之间采用的是读写分离的方式。
Redis 全量复制的三个阶段:
第一阶段:主从库间建立连接、协商同步的过程,主要是为全量复制做准备。在这一步,从库和主库建立起连接,并告诉主库即将进行同步,主库确认sigusoft后,主从库间就可以开始同步了。
具体来说,从库给主库发送 psync 命令,表示要进行数据同步,主库根据这个命令的参数来启动复制。psync 命令包含了主库的 runID 和复制进度 offset 两个参数。runID,是每个 Redis 实例启动时都会自动生成的一个随机 ID,用来唯一标记这个实例。当从库和主库第一次复制时,因为不知道主库的 runID,所以将 runID 设为“?”。offset,此时设为 -1,表示第一次复制。主库收到 psync 命令后,会用 FULLRESYNC 响应命令带上两个参数:主库 runID 和主库目前的复制进度 offset,返回给从库。从库收到响应后,会记录下这两个参数。这里有个地方需要注意,FULLRESYNC 响应表示第一次复制采用的全量复制,也就是说,主库会把当前所有的数据都复制给从库。
第二阶段:主库将所有数据同步给从库。从库收到数据后,在本地完成数据加载。这个过程依赖于内存快照生成的 RDB 文件。
具体来说,主库执行 bgsave 命令,生成 RDB 文件,接着将文件发给从库。从库接收到 RDB 文件后,会先清空当前数据库,然后加载 RDB 文件。这是因为从库在通过 replicaof 命令开始和主库同步前,可能保存了其他数据。为了避免之前数据的影响,从库需要先把当前数据库清空。在主库将数据同步给从库的过程中,主库不会被阻塞,仍然可以正常接收请求。否则,Redis 的服务就被中断了。但是,这些请求中的写操作并没有记录到刚刚生成的 RDB 文件中。为了保证主从库的数据一致性,主库会在内存中用专门的 replication buffer,记录 RDB 文件生成后收到的所有写操作。
第三个阶段:主库会把第二阶段执行过程中新收到的写命令,再发送给从库。具体的操作是,当主库完成 RDB 文件发送后,就会把此时 replication buffer 中的修改操作发给从库,从库再重新执行这些操作。这样一来,主从库就实现同步了。
Redis 增量复制的流程:
Redis 为什么主从全量复制使用RDB而不使用AOF?
1、RDB文件内容是经过压缩的二进制数据(不同数据类型数据做了针对性优化),文件很小。而AOF文件记录的是每一次写操作的命令,写操作越多文件会变得很大,其中还包括很多对同一个key的多次冗余操作。在主从全量数据同步时,传输RDB文件可以尽量降低对主库机器网络带宽的消耗,从库在加载RDB文件时,一是文件小,读取整个文件的速度会很快,二是因为RDB文件存储的都是二进制数据,从库直接按照RDB协议解析还原数据即可,速度会非常快,而AOF需要依次重放每个写命令,这个过程会经历冗长的处理逻辑,恢复速度相比RDB会慢得多,所以使用RDB进行主从全量复制的成本最低。
2、假设要使用AOF做全量复制,意味着必须打开AOF功能,打开AOF就要选择文件刷盘的策略,选择不当会严重影响Redis性能。而RDB只有在需要定时备份和主从全量复制数据时才会触发生成一次快照。而在很多丢失数据不敏感的业务场景,其实是不需要开启AOF的。
Redis 为什么还会有从库的从库的设计?
一次全量复制中,对于主库来说,需要完成两个耗时的操作:生成 RDB 文件和传输 RDB 文件。
如果从库数量很多,而且都要和主库进行全量复制的话,就会导致主库忙于 fork 子进程生成 RDB 文件,进行数据全量复制。fork 这个操作会阻塞主线程处理正常请求,从而导致主库响应应用程序的请求速度变慢。此外,传输 RDB 文件也会占用主库的网络带宽,同样会给主库的资源使用带来压力。那么,有没有好的解决方法可以分担主库压力呢?
其实是有的,这就是“主 - 从 - 从”模式。
在刚才介绍的主从库模式中,所有的从库都是和主库连接,所有的全量复制也都是和主库进行的。现在,我们可以通过“主 - 从 - 从”模式将主库生成 RDB 和传输 RDB 的压力,以级联的方式分散到从库上。
简单来说,我们在部署主从集群的时候,可以手动选择一个从库(比如选择内存资源配置较高的从库),用于级联其他的从库。然后,我们可以再选择一些从库(例如三分之一的从库),在这些从库上执行如下命令,让它们和刚才所选的从库,建立起主从关系。
replicaof 所选从库的IP 6379
这样一来,这些从库就会知道,在进行同步时,不用再和主库进行交互了,只要和级联的从库进行写操作同步就行了,这就可以减轻主库上的压力,如下图所示:
哨兵的核心功能是主节点的自动故障转移。下图是一个典型的哨兵集群监控的逻辑图:
哨兵的作用:
其中,监控和自动故障转移功能,使得哨兵可以及时发现主节点故障并完成转移;而配置提供者和通知功能,则需要在与客户端的交互中才能体现。
方式一:可能会导致锁一直没有释放
//加锁:如果键存在则不操作,否则操作 Boolean setIfAbsent(K, V );
setnx(K,V);
//释放锁: Boolean delete(K);
del(K);
方式二:可能出现上完锁后,服务器异常,不能设置过期时间(redis的命令不是原子操作)
//加锁:如果键存在则不操作,否则操作 Boolean setIfAbsent(K, V );
setnx(K,V);
//设置过期时间 Boolean expire(K key, final long timeout, final TimeUnit unit)
expire(K,Time);//单位:毫秒
//释放锁: Boolean delete(K);
del(K);
方式四:上锁同时设置过期时间;可能会发生锁误删除。
//加锁并设置过期时间 Boolean setIfAbsent(K key, V value, long timeout, TimeUnit unit);
setex(K,Time,V);//单位:毫秒
//释放锁: Boolean delete(K);
del(K);
方式五:上锁同时设置过期时间;将值设置为uuid,在进行释放锁时,先判断当前的uuid和要释放锁的uuid,若一致进行释放,否则不释放。
//1.进入方案 String requestId = IdWorker.getIdStr();
Boolean ret = redisTemplate.opsForValue().setIfAbsent( "key",requestId,5L,TimeUnit.SECONDS);
//2.判断为true 表示加锁成功,false标识锁已经存在 if(ret){
//3.执行业务
//4.执行结束 Object o = redisTemplate.opsForValue().get(key);
if(o !=null){
if(requestId.equals((String)o)){
redisTemplate.delete(key);
}
}
}else{
//5.做异常容错处理 Long expire = redisTemplate.opsForValue().getOperations().getExpire(key);
if(expire !=null && expire.intValue()<0){
redisTemplate.delete(key);
}
//6.日志打印该模块未执行任务! log.info("模块:"+MODULE+",定时任务已在执行!");
}
作者:怀揣着梦想出发的博客
链接:
https://
blog.csdn.net/m0_593477
46/article/details/125866201
来源:csdn
补充:Redis雪崩,击穿,穿透以及常见的应用场景
终端研发部:16个 Redis 常见使用场景
redis缓存雪崩,击穿,穿透,到底是什么?
大家看完有什么不懂的可以在下方留言讨论,也可以私信问我一般看到后我都会sigusoft的。最后觉得文章对你有帮助的话记得点个赞哦,点点不迷路
@终端研发部
每天专注技术开发小技巧,技术教程进阶,职场经验,面试的分享,希望我的回答能够帮助到你哈,笔芯~
今天的分享到此就结束了,感谢您的阅读,如果确实帮到您,您可以动动手指转发给其他人。