首页  思维导图  详情

Redis-Tree面试笔记

2025-10-20 12:42:25   0  举报





AI智能生成

Redis-Tree面试笔记

redis

缓存

面试

开发

八股文

作者其他创作

大纲/内容

类型

String（字符串）
List（列表）
Hash（哈希）
Set（集合）
ZSet（有序集合）

过期删除策略

定时删除：设置key过期时间同时创建一个定时器，定时器负责key过期时删除（对CPU不友好，时间换空间）。
惰性删除：在key被使用时才判断是否过期，对内存不友好，用存储空间换处理器性能（对内存不友好，空间换时间）。
定期删除：周期性的轮询查找时效性数据，默认1秒10次（100毫秒/次，通过hz配置），采用随机抽取的策略，利用过期数据占比的方式控制删除频度（随机抽查）。
1）测试随机的20个keys进行相关过期检测。
2）删除所有已经过期的keys。
3）如果还有多于25%的keys过期，重复步奏1。
假设Redis当前存放30万个key，并且都设置了过期时间，如果每隔100ms就去检查这全部的key，CPU负载会特别高，最后可能会挂掉。因此，redis采取的是定期过期，每隔100ms就随机抽取一定数量的key来检查和删除。但是呢，最后可能会有很多已经过期的key没被删除。这时候，redis采用惰性删除。在获取某个key的时候，redis会检查一下，这个key如果设置了过期时间并且已经过期了，此时就会删除。
但是呀，如果定期删除漏掉了很多过期的key，然后也没走惰性删除。就会有很多过期key积在内存，直接会导致内存爆掉。或者有些时候，业务量大起来了，redis的key被大量使用，内存直接不够了，运维小哥哥也忘记加大内存了。难道redis直接这样挂掉？不会的！Redis用8种内存淘汰策略保护自己~

内存淘汰策略

触发时机：当内存超过maxmemory限制时，使用maxmemory-policy指定的策略进行内存回收。
1、noevication : 不会驱逐任何 key (默认)
2、allkeys-lru: 对所有的 key 使用 lru 算法进行删除
3、volatile-lru: 对所有的设置了过期时间的 key 进行 lru 算法进行删除
4、allkeys-random: 对所有 key 随机删除
5、volatile-random: 对所有设置了过期时间的 key 随机删除
6、volatile-ttl ：马上删除要过期的 key
7、allkeys-lfu: 对所有 key 进行 lfu 算法进行删除
8、volatile-lfu: 对所有设置了过期时间的 key 使用 lfu 算法进行删除
LRU算法（最近最少使用）：以访问时间为参考，淘汰最早被访问的数据（LRU=哈希+链表，可以用LinkedHashMap实现LRU）。
LFU算法（最不经常使用）：以访问频率为参考，淘汰最少访问频率的数据。、
配置：
1、配置文件：maxmemory-policy allkeys-lru
2、客户端命令：config set maxmemory-policy allkeys-lru（设置）
config get maxmemory-policy（查看）

RDB持久化

RDB（默认开启）：在某一些刻以（全量）快照形式将内存中的数据写入到磁盘（忽略已过期key），生成dump.rdb（经过压缩的二进制数据文件）。
0、fork()会产生一个和父进程完全相同的子进程(除了pid)。
1、RDB持久化时（bgsave），父进程会fork出一个子进程，由子进程对数据进行I/O写到磁盘。如果在这个过程中发生写操作，Redis会借助操作系统提供的写时复制技术（Copy-On-Write, COW），在执行快照的同时，依然可以正常处理写操作，同时当前主进程写操作的内容也会写入RDB。
2、恢复RDB数据：如果指定目录中存在dump.rdb文件（主：忽略已过期key，从：不忽略），重启redis服务时（需要将AOF关闭）。
配置
1、save 900 1 ：#900秒(15分钟)内，如果有1个key发生变化，自动触发bgsave命令创建快照。
2、关闭RDB：注释所有save规则，设置为空save ""，删除dump.rdb，重启redis服务。
3、dbfilename ：设置快照的文件名，默认是 dump.rdb。
4、dir：设置快照文件的存放路径（目录）。
命令
lastsave：获取最后一次成功执行快照的时间。
save：阻塞进程，直到RDB完成，阻塞期间不能处理任何命令。、
bgsave：派生出一个子进程处理RDB，不会影响父进程处理其他命令。

AOF持久化

AOF：根据指定的策略，以日志形式将改变数据集的操作命令追加到appendonly.aof文件中。
1、AOF持久化时，父进程会fork出一个子进程，由子进程对数据进行IO写到磁盘。为了提升写入效率，不会将内容直接写入到磁盘中，而是将其放到一个内存缓存区（buffer）中，等到缓冲区写满或调用fsync()函数时才真正将缓存区中的内容写入到磁盘里。
2、恢复AOF数据：Redis重启，如果RDB、AOF同时存在，默认加载AOF。
配置
1、appendonly no # 是否开启aof
2、appendfilename "appendonly.aof" # 文件名
3、磁盘同步策略（默认每秒一次）
appendfsync always # 每次对数据集操作执行一次fsync
appendfsync everysec # 每秒执行一次fsync
appendfsync no # 由操作系统执行，默认Linux配置最多丢失30秒
4、AOF重写策略，AOF文件体积过大时，将重复指令优化成1条指令
auto-aof-rewrite-percentage 100 #百分比，第一次64mb时重写，第二次128mb，第三次等再次增加64mb（100%）
auto-aof-rewrite-min-size 64mb #表示触发AOF重写的最小文件体积，大于或等于64MB自动触发。
命令
1、bgrewriteaof重写AOF

Redis4.0后，混合持久化策略（必须开启AOF），相当于AOF升级版，区别在于当AOF重写时，会将已有的内容优化成RDB二进制的内容存储。
aof-use-rdb-preamble yes #开启混合持久化

高可用

主从复制

介绍

1、避免单点故障和读写不分离，Redis提供了复制（replication）功能实现主节点中的数据更新后自动同步到其他从节点上
2、Redis主从结构特点：一个主节点可以有多个从节点，从节点可以有从节点（级联结构）。

主从节点

主节点
1、可读写
2、将写入的数据同步至从节点（异步处理，保证AP）
3、一主多从

从节点
1、只可读
2、只能关联一个主节点
3、从节点可以接受其他从节点连接

优缺点

优点
1、读写分离
2、通过扩容从节点，提高主从架构QPS
2、做容灾恢复

缺点
1、不具备自动容错和恢复功能，主节点宕机需要人工介入

数据同步

全量同步
1、从节点连接主节点，发送SYNC命令；
2、主节点接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
3、主节点BGSAVE执行完后，向所有从节点发送快照文件，并在发送期间继续记录被执行的写命令；
4、从节点收到快照文件后丢弃所有旧数据，载入收到的快照；
5、主节点快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6、从节点完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

增量同步
1、主节点每执行一个写命令就会向从节点发送相同的写命令，从节点接收并执行收到的写命令。

哨兵模式

介绍

1、哨兵模式核心还是主从复制，只不过在相对于主从模式在主节点宕机导致不可写的情况下，多了一个竞选机制：从所有的从节点竞选出新的主节点（竞选机制的实现，是依赖于在系统中启动一个sentinel进程）。
2、哨兵本身也有单点故障的问题，所以在一个一主多从的Redis系统中，可以使用多个哨兵进行监控，哨兵不仅会监控主数据库和从数据库，哨兵之间也会相互监控。每一个哨兵都是一个独立的进程。

优缺点

优点
1、哨兵模式基于主从模式，具有主从的优点
2、自动故障切换，保证高可用

缺点
1、故障切换时服务不可用
2、始终只有一个主节点接收和处理写请求，写操作受单机瓶颈影响
3、集群里所有节点保存的都是全量数据，浪费内存空间，没有真正实现分布式存储
4、数据量过大时，全量同步影响主节点性能

故障切换

主观下线

哨兵1向主节点发送Ping，在一定时间内未收到Pong回复，此时该哨兵1认为该主节点“主观下线”

客观下线

哨兵1发现主节点“主观下线”，询问其他哨兵节点，如果超过半数认为主节点宕机，则认定为“客观下线”

投票选举

一般哪个哨兵节点最先判断出这个主节点“客观下线”，就会在各个哨兵节点中发起投票机制Raft算法（选举算法），最终被投为领导者的哨兵节点完成主从自动化切换的过程，通过发布订阅模式通知其他的从节点，修改配置，切换主节点

从节点升级策略

1、优先级：redis.conf中slave-priority 100（值越小优先级越高）

2、偏移量：获取原主数据最多的

3、runid：每个Redis启动会随机生成一个40位的runid，最小的优先

原理

哨兵启动后与主节点建立两条连接
1、订阅主节点 _sentinel_:hello 频道以获取同样监控该数据库的哨兵节点信息
2、定期向主数据库发送info命令，获取主节点本身的信息

哨兵与主节点建立连接后会定时执行以下三个操作
1、每隔10s向所有主从节点发送info命令。作用是获取当前节点信息，比如发现新增从节点时会建立连接，并加入到监控列表中；当主节点的角色发生变化后进行信息更新
2、每隔2s向所有主节点的 _sentinel_:hello 频道发送自己的信息。作用是将自己的监控数据和哨兵分享，每个哨兵会订阅节点的_sentinel:hello 频道，当其他哨兵收到消息后，会判断该哨兵是不是新的哨兵，如果是则将其加入哨兵列表，并建立连接
3、每隔1s向所有主从节点和所有哨兵节点发送ping命令，监控节点是否存活

分片集群

介绍

1、Cluster模式为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器，内存/QPS 不受限于单机，可受益于分布式集群高扩展性。
2、Redis Cluster 是一种服务器Sharding技术(分片和路由都是在服务端实现)，采用多主多从，每一个分区都是由一个Redis主机和多个从机组成，片区和片区之间是相互平行的。Redis Cluster集群采用了P2P的模式，完全去中心化。

优缺点

优点

1、集群中有多个主节点，每个主节点保存不同数据
2、客户端请求可以访问集群任意节点，最终都会被转发到正确节点
3、主节点之间通过ping监测彼此健康状态
4、每个主节点都可以有多个从节点

缺点

1、从节点不做读写，只负责备份主节点数据
2、故障切换时服务不可用

分片算法

Redis Cluster采用的算法
类似一致性哈希算法：例如一致性哈希是对2^32取模，而Redis Cluster则是对2^14（也就是16384）取模。Redis Cluster将自己分成了16384个Slot（槽位）。通过（槽定位算法）CRC16算法计算出来的哈希值会跟16384取模，取模之后得到的值就是对应的槽位，然后每个Redis节点都会负责处理一部分的槽位

为什么不用哈希算法来进行实例选择？
如果某台主节点宕机，将导致Redis中所有的缓存失效：比如当前3台主节点（hash%3），一台宕机后（hash%2）

集群如何进行扩容

1、通过reshard（重新分片）来实现。reshard可以将已经分配给某个节点的任意数量的slot迁移给另一个节点，在Redis内部是由redis-trib负责执行的。可以理解为Redis其实已经封装好了所有的命令，而redis-trib则负责向获取slot的节点和被转移slot的节点发送命令来最终实现reshard。
2、假设我们需要向集群中加入一个D节点，而此时集群内已经有A、B、C三个节点了。此时redis-trib会向A、B、C三个节点发送迁移出槽位的请求，同时向D节点发送准备导入槽位的请求，做好准备之后A、B、C这三个源节点就开始执行迁移，将对应的slot所对应的键值对迁移至目标节点D。最后redis-trib会向集群中所有主节点发送槽位的变更信息。

高可用及故障切换

1、某一个节点认为主节点A宕机了，此时是“主观宕机”。而如果集群内超过半数的节点认为A挂了，此时A就会被标记为“客观宕机”。
2、一旦主节点A被标记为了“客观宕机”，集群就会开始执行故障转移。其余正常运行的主节点会进行投票选举，从A节点的从节点中选举出一个，将其切换成新的主对外提供服务。当某个从获得了超过半数的主节点投票，就成功当选。

扩展

Redis是单线程还是多线程？
1、6.0前：网络I/O、读写命令由单线程完成，持久化与集群数据同步是多线程。
2、6.0后：读写命令仍然是单线程处理，而网络I/O采用了多线程。
Redis单线程为什么这么快？
1、命令执行基于内存操作
2、没有线程切换开销
3、基于IO多路复用
4、底层高效存储结构
删除Key会阻塞Redis吗？
1、O(N)，N为被删除key的数量
2、删除单个字符串，时间复杂度O(1)
3、删除单个列表、集合、有序集合、哈希，时间复杂度O(M)，M为元素数量
结论：集合会逐个元素遍历删除（阻塞），超大字符串（阻塞）
缓存穿透
表示请求的数据在缓存、数据库都不存在，穿过了缓存，透过了数据库，还是没有数据。
场景：遭到恶意攻击，传入一个根本不存在的值产生大量请求，如id=-1，可能导致DB压力过大挂掉。
解决：
1）做参数校验，过滤掉非法无效参数。
2）缓存空值，如id=-1不存在，也缓存一个key=empty:-1，同时设置过期时间。
3）BloomFilter（布隆过滤器），系统启动时将需要检查的缓存数据存入，请求来的时候先去BloomFilter查询key是否存在，不存在则直接返回，存在则查缓存、查DB，布隆过滤器也存在一定的误判。
缓存击穿
请求将Redis击穿，到达DB层，可以看做小规模雪崩（击穿是一个人的雪崩，雪崩是一群人的击穿）。
场景1：某时刻一批热点数据同时过期失效，那么这一刻的所有请求将访问DB，使DB压力剧增。
场景2：突然爆发大量并发请求一个未被缓存的冷门数据，如微博热点事件。
解决：
1）对热点数据的过期时间设置尽可能分散，基础值+2分钟内的随机时间(具体随机范围看实际业务)，避免同一时间大批量缓存失效。
2）增加分布式DCL读写锁。
3）在业务层监控热点数据是否即将过期，如果即将过期则去数据库获取最新数据进行更新并延长该热点key在缓存系统中的时间。
缓存雪崩
缓存雪崩的主要原因是缓存系统不够高可用，间接导致整个系统不可用。
场景1：在单节点主从架构，突发的大量并发请求（10W+）直接访问Redis，导致Redis承载不住挂掉。
解决：
1）限流：各级负载均衡层根据后端相关接口的压测指标针对性的做限流控制，避免同时处理大量的请求。
2）多级缓存架构：如在JVM层做一个进程级缓存，当该缓存没有数据时才查询Redis。
3）Redis集群避免单点故障。
场景2：大量并发请求场景，缓存大面积过期失效，未被Redis缓存承接住，直接请求到DB，导致DB挂掉。
解决：对热点数据的过期时间设置尽可能分散，一个较大固定值+一个较小的随机值(具体随机范围看实际业务)，避免同一时间大批量缓存失效。
分布式锁
分布式锁需要解决的问题：
1、使用setnx实现分布式锁，并在finally中释放锁
2、问题 - 在finally前程序终止，锁未释放
解决 - 设置锁超时时间。
3、问题 - 如果先加锁再设置超时时间可能存在加锁后，设置超时时间之前程序down了
解决 - 使用setex保证原子操作
4、问题 - 锁5s过期，A线程执行业务逻辑用了6秒，第5秒释放锁后B线程拿到锁，这时A线程会删除B线程的锁。
解决 - 加锁线程设置唯一标识到value中，解锁前先检查，是自己加的锁才允许删除。
5、问题 - 锁检查与锁释放不是原子操作
解决 - Lua表达式：检查、删除封装成一条脚本执行，保证原子性
6、问题 - 业务执行时间大于锁过期时间，导致线程A任务还未执行完但锁被释放，其他线程获取锁后进行业务操作
解决 - 锁续期（Redisson：默认30s超时，10s一次续期），加锁redisson.lock();解锁redison.unlock();
7、问题 - 在高并发情况下，使用redisson.unlock()解锁可能出现IllegalMonitorStateException异常（需要创建锁的线程进行解锁）
解决 - if(redisson.isLocked() && redisson.isHeldByCurrentThread()){redisson.unlock();}

Redis分布式集群倾斜问题

1、数据存储容量倾斜，数据存储总是落到集群中少数节点
2、QPS请求倾斜，QPS总是落到少数节点

倾斜的影响

1、QPS集中到少数redis节点，引起少数节点过载，会拖垮整个服务，同时集群处理QPS能力不具备可扩展性；
2、数据容量倾斜，导致少数节点内存爆增，出现OOM Killer和集群存储容量不具备可扩展性；
3、运维管理变复杂，类似监控告警内存使用量、QPS、连接数、redis cpu busy等值不便统一；
4、因集群内其他节点资源不能被充分利用，导致redis服务器/容器资源利率低；
5、增大自动化配置管理难度；单集群节点尽量统一参数配置；

倾斜的常见原因

1、系统设计时，redis键空间(keyspace)设计不合理，出现”热点key",导致这类key所在节点qps过载，集群出现qps倾斜；
2、系统存在大的集合key(hash,set,list等)，导致大key所在节点的容量和QPS过载，集群出现qps和容量倾斜；
3、DBA在规划集群或扩容不当，导致数据槽(slot)数分配不均匀，导致容量和请求qps倾斜;
4、系统大量使用[Keys hash tags](http://redis.io/topics/cluster-spec), 可能导致某些数据槽位的key数量多，集群集群出现qps和容量倾斜；
5、工程师执行monitor这类命令，导致当前节点client输出缓冲区增大；used_memory_rss被撑大；导致节点内存容量增大，出现容量倾斜；

倾斜问题的排查方式

1、排查节点热点key,确定top commands.
当集群因热点key导致集群qps倾斜，需快速定位热点key和top commands。可使用开源工具[redis-faina]
2、系统是否使用较大的集合键
系统使用大key导致集群节点容量或qps倾斜，比如一个5kw字段的hash key, 内存占用在近10GB，这个key所在slot的节点的内存容量或qps都很有可能倾斜。
3、检查集群每个分片的数据槽分配是否均匀
4、系统是否大量使用keys hash tags
5、是否因为client output buffer异常，导致内存容量倾斜

如何有效避免Redis集群倾斜

1、系统设计redis集群键空间和query pattern时，应避免出现热点key, 如果有热点key逻辑，尽量打散分布不同的节点或添加程序本地缓存；
2、系统设计redis集群键空间时，应避免使用大key，把key设计拆分打散；大key除了倾斜问题，对集群稳定性有严重影响；
3、redis集群部署和扩缩容处理，保证数据槽位分配平均；
4、系统设计角度应避免使用keys hash tag；
5、日常运维和系统中应避免直接使用keys,monitor等命令，导致输出缓冲区堆积；这类命令建议作rename处理；
6、合量配置normal的client output buffer, 建议设置10mb,slave限制为1GB按需要临时调整(警示:和业务确认调整再修改，避免业务出错)
在实际生产业务场景中，大规模集群很难做到集群的完全均衡，只是尽量保证不出现严重倾斜问题。