相关文章:
【Redis面试】基础题总结(中)
【Redis面试】基础题总结(下)
有关redis基础知识见专栏:Redis
面试(上)
1.Redis是单线程还是多线程?
答:redis6.0版本之前的单线程指的是其网络i/o和键值对读写是由一个线程完成的
redis6.0引入的多线程是指网络请求过程采用了多线程,而键值对的读写仍然是单线程,所以redis依然是并发安全的
也即是说只有网络请求模块和数据操作模块是单线程的,而它的持久化,集群数据同步等,其实是额外的线程执行的。
2.redis单线程为什么还能这么快?
1.命令执行是基于内存的,一条命令在内存里才操作的时间是几十纳秒
2.命令执行是单线程的,没有线程切换的开销
3.基于多路复用机制提升redis的i/o利用率
4.高效的数据存储结构:全局hash表以及多种高级数据结构。比如:跳表,压缩列表,链表等等。
4.redis底层是如何用调表来存储的?
答:调表:将有序链表改造为近似折半查找算法,可以快速进行插入,删除,查找操作。
5.redis设置的key过期了为什么没有释放内存?
答:1.在设置key的时候,设置了过期时间,在key还没有过期的这段时间内,重新设置了这个key的值,没有设置过期时间,那么这个key就永久存在了。
2.redis对于过期的key的处理一般有惰性删除和定时删除两种策略
惰性删除:当读写一个已过期的key时,会触发惰性策略,判断key是否过期,如果过期了直接删掉。
定时删除:由于惰性删除无法保证冷数据及时的被删除掉,所以redis会将设置了过期时间的key放到一个独立的字典中,并对该字典每秒进行10次 的扫描,扫描不会全部扫描,
这里采用的时一种简单的贪心策略。逻辑如下:
a.从过期字典中随机选择20个key
b.删除20个中已过期的lkey
c.如果已过期key的比例超过25%,则重复步骤a。
6.redis中key没设置过期时间,为啥被redis主动删除了?
答:当redis已用内存超过maxmemory限定时,触发主动清理策略
主动清理策略在redis4.0之前,有6中,4.0之后又加了两种共8种。
针对设置了过期时间的key的处理策略:
1.volatile-ttl:在筛选时,会针对设置了过期时间的键值对,根据过期时间的先后顺序进行删除。
2.volatile-random:在设置了过期时间的key中进行随机删除
3.volatile-lru:会使用LRU算法筛选设置了过期时间的键值对进行删除
4.volatile-lfu:会使用lfu算法
针对所有key进行处理
5.allkeys-random:从所有键值对中随机选择并删除数据
6.allkeys-lru:使用LRU算法在所有数据中删除
7.allkeys-lfu:使用lfu算法
8.noeviction:不会剔除任何数据,拒绝所有的写入操作,并返回客户端信息错误“OOM command not allowed when used memory”,此时redis只响应读操作。
LRU(Least Recently Used)是按照最近最少使用原则来筛选数据,即最不常用的数据会被筛选出来!
7.redis淘汰key的算法LRU与LFU
LRU算法:(Least Recently Used 最近最少使用),淘汰很久没被访问的数据,以最近一次访问时间作为参考)
LFU算法:(Least Frequently Used 最不经常使用),淘汰最近一段时间访问次数最少的数据,以次数作为参考。
绝大多数采用LRU策略,当存在大量热点缓存数据时,LUF可能更好
标准LRU:把所有的数据组成一个链表,表头和表尾分别表示MRU和LRU端,即最常使用端和最少使用端。刚被访问的数据会被移动到MRU端,而新增的数据也是刚被访问的数据,也会被移动到MRU端。当链表的空间被占满时,它会删除LRU端的数据。
近似LRU:Redis会记录每个数据的最近一次访问的时间戳(LRU)。Redis执行写入操作时,若发现内存超出maxmemory,就会执行一次近似LRU淘汰算法。近似LRU会随机采样N个key,然后淘汰掉最旧的key,若淘汰后内存依然超出限制,则继续采样淘汰。可以通过maxmemory_samples配置项,设置近似LRU每次采样的数据个数,该配置项的默认值为5。
LRU算法的不足之处在于,若一个key很少被访问,只是刚刚偶尔被访问了一次,则它就被认为是热点数据,短时间内不会被淘汰。
LFU算法正式用于解决上述问题,LFU(Least Frequently Used)是Redis4新增的淘汰策略,它根据key的最近访问频率进行淘汰。LFU在LRU的基础上,为每个数据增加了一个计数器,来统计这个数据的访问次数。当使用LFU策略淘汰数据时,首先会根据数据的访问次数进行筛选,把访问次数最低的数据淘汰出内存。如果两个数据的访问次数相同,LFU再比较这两个数据的访问时间,把访问时间更早的数据淘汰出内存。
8.redis的主从同步是如何实现的?
从版本2.8开始。redis使用psync命令来完成主从数据同步,同步过程分为全量复制和部分复制,全量复制一般用于初次复制的场景,部分复制用于处理网络中断等原因造成的数据丢失的场景,psync命令需要以下参数的支持:
1.复制偏移量:主节点处理写命令后,会把命令长度做累加记录,从节点在接收到写命令后,也会做累加,从节点会每秒上报一次自身的复制偏移量给主节点,而主节点会保存从节点的复制偏移量
2.挤压缓冲区:保存在主节点上的一个固定长度队列,默认为1m,当主节点有连接的从节点时被创建,主节点处理写命令时,不但会把命令发送给从节点,还会写如挤压缓冲区,缓存区是先进先出的队列。可以保存最近已复制的数据,用于部分复制和命令丢失时的数据补救。
3.主节点运行id:每个redis节点启动之后都会动态分配一个40位的16进制字符串作为运行id,如果使用ip和端口的方式标识主节点,那么主节点重启后变更了数据集(RDB/AOF),从节点再基于复制偏移量复制数据是不安全的,因此当主节点的id变化后,从节点将做全量复制。
psync命令的执行过程及返回结果,如下图:
a,若回复+FULLRESYNC,则从节点将触发全量复制;
b,若回复+CONHTINUE,则从节点触发部分复制;
c,若回复-err,说明主节点版本过低,无法识别psync命令
9.如何实现redis的高可用?
实现redis的高可用主要有哨兵模式和集群两种方式:
哨兵:
redis sentinel 是一个分布式架构,它包含若干个哨兵节点和数据节点。每个哨兵节点会对数据节点和其余哨兵节点进行监控,当发现节点不可达时会对节点做下标识。如果被标识的是主节点,它就会与其他哨兵节点进行协商,当多数哨兵节点认为主节点不可达时,他们会选举一个哨兵节点来完成自动故障转移的工作,同时还会将这个变化实时的通知给应用方,整个过程是自动的,不需要人工介入,有效解决了redis的高可用问题。
哨兵模式的特征:
1.会定期监控数据节点,其他哨兵节点是否可达
2.会将故障转移的结果通知给应运方
3.可以将从节点晋升为主节点,并维护后续的主从关系
4.哨兵模式下,客户端连接的是哨兵节点集合,从中获取主节点的信息
5.节点的故障判断是由多个哨兵共同完成的,可以防止误判
6.哨兵节点集合是由多个哨兵节点组成的,即使个别节点不可以,整个集合依然是健壮的
7.哨兵节点也是独立的redis节点,他们不存储数据,只支持部分命令
集群:
redis集群采用虚拟槽区分来实现数据分片,它把所有的键根据哈希函数映射到0-16383整数槽内,计算公式为slot=CRC165(key)&16383,每一个节点负责维护一部分槽及槽所映射的键值数据,
虚拟槽区分具有的特点:
1.解耦数据和节点之间的关系,简化了节点扩容和收缩的难度
2.节点自身维护槽的映射关系,不需要客户端或代理服务维护槽分区元数据
3.支持节点,槽,键之间的映射查询,用于数据路由,在线伸缩等场景。
10.缓存穿透,缓存击穿,缓存雪崩有什么区别,该如何解决?
缓存穿透:
问题描述:客户端查询根本不存在的数据,使得请求直达存储层,导致其负载过大,甚至宕机。出现这种状况的原因,可能是业务层将缓存和库中的数据删除了,也可能是人为恶意攻击,专门访问不存在的数据。
解决方案:1.缓存空对象,存储层未命中后,仍将空值存入缓冲层,客户端再次访问数据时,缓冲层会直接返回空值。
2.布隆过滤器:将数据存入布隆过滤器,访问缓存之前以过滤器拦截,若请求的数据不存在直接返回空值。
缓存击穿:
问题描述:一份热点数据,它 的访问量非常大,在其缓存失效的瞬间,大量请求直达存储层,导致服务崩溃。
解决方案:1.永不过期:热点数据不设置过期时间,这是物理层上的永不过期。或者为每个数据设置逻辑过期时间,当发现数据逻辑过期时,使用单独的线程重新缓存。
2.加互斥锁:对数据的访问加互斥锁,当一个线程访问数据时,其他线程只能等待,这个线程访问过后,缓存中的数据将被重建,届时其他线程就可以直接从缓存中获取
缓存雪崩:
问题描述:在某一时刻缓存层无法继续提供服务,导致所有的请求直达存储层,导致数据库宕机。可能时缓存中大量数据同时过期,也可能是redis节点发生故障,导致大量请求无法的到处理。
解决方案:1.避免数据同时过期:设置过期时间时,附加一个随机数,避免大量key同时过期。
2.启用降级和熔断措施:在发生雪崩时,若访问的数据不是核心数据,则直接返回预定义信息/空值/错误信息。或者在发生雪崩时,对于访问缓存接口的请求,客户端并不会把请求发给redis,而是直接返回。
3.构建高可用的redis服务:采用哨兵或集群模式,部署多个redis实例,个别节点宕机,依然可以保持服务的整体可用。
11.redis的持久化策略
redis支持rdb持久化,aof持久化,rdb-aof混合持久化三种
RDB:
redis DataBase,是redis默认采用的持久化方式,它以快照的方式将数据持久化到硬盘中,rdb会创建一个经过压缩的二进制文件,以.rdb结尾,内部存储了各个数据库的键值对数据等信息,rdb持久化的触发方式有两种:
1.手动触发;通过SAVE和BGSAVE命令触发rdb持久化操作,创建.rdb文件;
2.自动触发:通过配置选项。让服务器在满足指定条件时自动执行BGSAVE命令。
其中SAVE命令执行期间,redis服务器将阻塞,知道.rdb文件创建完毕为止,而BGSAVE命令是异步版本的SAVE命令,它会使用redis服务器进程的子进程,创建.rdb文件。BGSAVE命令在创建子进程时会存在短暂的阻塞,之后服务器便可以继续处理其他客户端的请求。总之,BGSAVE命令是针对SAVE阻塞问题做的优化。redis内部所有涉及RDB的操作都采用BGSAVE的方式,而save命令已废弃
RDB持久化的优缺点如下:
优:RDB生成紧凑的压缩的二进制文件,体积小,使用该文件恢复数据的速度非常快
缺:BGSAVE每次运行都要执行fork操作创建子进程,属于重量级操作,不宜频繁执行
所以RDB持久化没办法做到实时的持久化
AOF:
Append Only File,解决了数据持久化的实时性,是目前redis持久化的主流方式,aof以独立日志的方式,记录了每次写入命令,重启时重新执行aof文件中的命令来恢复数据。工作流程为:
命令写入(append),文件同步(sync),文件重写(rewrite),重写加载(load)
aof以文本协议格式写入命令,eg:
*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n
文本协议的优点:
1.具有很好的兼容性
2.直接采用文本协议格式,可以避免二次处理的开销
3.文本协议具有可读性,方便直接处理和修改
AOF持久化的同步机制:
为了提高程序的写入性能,现代操作系统会把针对磁盘的多次操作优化为一次操作
1.当程序调用write对文件写入时,系统不会直接写入硬盘,而是写入缓冲区
2.当达到指定时间周期或缓冲区写满时,系统才会执行flush操作,将缓冲区中的数据洗至磁盘中
这种优化机制虽然提高了性能,但是给程序的写入带来了不确定性
1.对于aof这样的持久化功能来说,冲洗机制将直接影响aof持久化的安全性
2.为了消除不确定性,redis向用户提供了appendfsync选项,来控制系统冲洗aof的频率;
3.linux的glibc提供了fsync函数,可以将指定文件强制从缓冲区刷到硬盘,上诉选项正是基于此函数
AOF的优缺点:
优:与RDB持久化可能丢失大量数据相比,aof持久化安全性更高,通过everysec选项,用户可以将数据丢失的时间窗口限制在1秒以内
缺:文本协议比二进制大得多,aof需要通过执行aof文件中的命令来恢复数据库,其恢复速度比rdb慢,aof在进行重写时也需要创建子进程,在数据库体积较大时将占用大量资源,会导致服务器短暂阻塞。
RDB-AOF混合持久化:
从4.0开始引入,这种模式是基于aof持久化构建而来的,用户可以通过配置文件的aof-user-preamble yes配置项开启aof混合持久化,redis服务器在执行aof重写操作时,会按如下原则处理数据:
1.像执行BGSAVE一样,根据数据库当前状态生成对应的rdb数据,并写入aof中
2.对于重新之后执行的redis命令,则以协议文本的方式追加到aof文件的末尾,即rdb数据之后
通过使用混合持久化,用户可以同时获得rdb持久化和aof的优点,服务器可以通过aof文件包含rdb数据来实现快速的数据恢复操作,又可以通过aof文件包含的aof数据来将丢失数据的时间窗口设置在1s内。
12.redis线上数据如何备份?
1.写crontab定时调度脚本,每小时都copy一份rdb或aof到另外一台机器中去,保持最近48小时的备份
2.每天都保留一份当日的数据备份到一个目录中去,可以保留最近一个月的
3.每次copy的时候,都把太旧的备份给删了
13.如何保证缓存与数据库的双写一致性?
四种同步策略:
要想保证缓存与数据库的双写一致,有四种:
1.先更新缓存,在更新数据库
2.先更新数据库,再更新缓存
3.先删除缓存,再更新数据库
4.先更新数据库,再删除缓存
问题1:更新与删除缓存哪种方式更合适?
更新:
优:每次数据变化都及时更新,所以查询时不容易出现未命中的情况
缺:更新缓存消耗大,数据需要经过复杂的计算再写入缓存,频繁的更新操作就会影响服务器的性能,如果是写入数据频繁的业务场景,那么可能频繁的更新缓存时,却没有业务读取该数据
删除:
优:操作简单,无论更新是否复杂,都将缓存中数据删除
缺:删除缓存后,下一次查询缓存会出现未命中,这时需要重新读取一次数据库
从上面的比较来看,一般情况下,删除缓存是更优的方案。
问题2:先操作数据库还是先操作缓存?
在两步操作都正常的情况下:
a:删除缓存,再更新数据库
1.进程A删除缓存
2.进程B读取缓存失败
3.进程B读取数据库成功,得到旧的数据库
4.进程B将旧的数据更新到缓存
5.进程A将新的数据更新到数据库
最终:数据库和缓存二者数据不一致
b:更新数据库,再删除缓存:
1.进程A更新数据库
2.进程B查询缓存成功
3.进程A删除缓存
可见最终缓存和数据库的内容时是一致的虽然B读到了旧的数据,但是这两步的执行速度快影响不大
最终结论:先更新,再删除缓存是影响更小的方案。
当然如果根据实际情况不得不使用先删除,再更新,则可以通过延时双删的策略解决,具体如下:
1.删除缓存;
2.更新数据库;
3.sleepN毫秒;
4.再次删除缓存;
阻塞一段时间后,再次删除缓存,就可以把这个过程中缓存的不一致数据删掉。
如果是读写分离的结构:
进程A先删除缓存,再更新数据库,然后主同步到从,而在同步之前,可能会有进程B访问了缓存,当发现数据不存在时,会从数据库访问,然后同步到缓存,这样也会导致不一样,这个问题解决方案依然时采用双删的策略,但是在评估延长时间的时候,要考虑主从数据库同步的时间。
第二次删除失败了则么办?
依然增加重试的次数,但次数要有限制,超出限制后要采用报错,记日志,发邮件提醒等措施。
如果两步中出现失败时,无法判断哪个更好。出现失败时采用重试机制解决。
以先更新,再删除为例:
1.更新数据库成功;
2.删除缓存失败;
3.将此数据加入消息队列;
4.业务代码消费这条数据;
5.业务代码根据这条消息的内容,发起重试机制,即从缓存中删除这条记录。