【Redis】经典面试题总结-史上最全面试题思维导图总结

2022-10-22 13:49:03   20  举报





AI智能生成

这份思维导图总结了Redis的经典面试题，涵盖了从基础知识到高级应用的各个方面。包括了Redis的数据结构、持久化机制、缓存策略、分布式锁、事务处理等核心内容。同时，还涉及到了Redis的性能优化、集群部署、主从复制等高级主题。这份思维导图不仅能够帮助面试者系统地复习和准备Redis的知识，也能够帮助他们在实际工作中更好地理解和应用Redis。总的来说，这是一份全面而深入的Redis面试题总结，对于任何想要深入学习Redis的人来说都是一份宝贵的学习资料。

redis

java面试

面试

java

数据库

作者其他创作

大纲/内容

缓存异常

缓存雪崩

缓存同一时间大面积的失效

过期时间设置随机，防止同一时间大量数据过期现象发生

加锁排队

缓存穿透

缓存和数据库中都没有的数据

接口层增加校验，id<=0的直接拦截

将key-value对写为key-null，缓存有效时间可以设置短点，如30秒。防止反复用同一个id暴力攻击

布隆过滤器判断在不在数据库

哈希表，多次hash

有一定的误识别率和删除困难

所有的Hash函数告诉我们该元素在集合中，才能确定在集合中

缓存击穿

热点数据缓存时间到期

设置热点数据永远不过期

加互斥锁

缓存预热

将相关的缓存数据直接加载到缓存系统

缓存降级

根据一些关键数据进行自动降级，也可以配置开关实现人工降级

Redis出现问题，不去数据库查询，而是直接返回默认值给用户

数据库双写时的数据一致性

先更新数据库，然后再删除缓存

一致性：缓存删除失败，数据不一致

高并发下：A去查突然失效查脏数据，B更新数据库，B写入缓存，A写入缓存->数据不一致

先删除缓存，然后再更新数据库

高并发下：A删除，B读数据库脏数据，B写入，A更新数据库->数据不一致

不更新缓存

有大量冷数据占用资源，用到缓存才去算缓存

集群方案

哨兵模式

集群监控：负责监控 redis master 和 slave

消息通知：如果某个 redis 实例有故障，通知给管理员。

故障转移：如果 master node 挂掉了，会自动转移到 slave node 上。

判断一个 master node 是否宕机了，大部分的哨兵都同意，分布式选举

配置中心：故障转移，通知 client 客户端新的 master 地址。

核心知识

至少需要 3 个实例

哨兵 + redis 主从的部署架构，是不保证数据零丢失的，只能保证高可用性。

Cluster 方案(服务端路由查询)

分布式寻址算法

hash 算法（大量缓存重建）

一致性 hash 算法（自动缓存迁移）+ 虚拟节点（自动负载均衡解决数据倾斜问题）

redis cluster 的 hash slot哈希槽算法 16384

主从架构

每份数据分片会存储在多个互为主从的多节点

多个节点间的数据不保持一致性

先写主节点，再同步到从节点(支持配置为阻塞同步)

当客户端操作的key没有分配在该节点上时，redis会返回转向指令，指向正确的节点

扩容时时需要需要把旧节点的数据迁移一部分到新节点

优点

支持动态扩容

具备Sentinel的监控和自动Failover(故障转移)能力

免去了proxy代理的损耗

连接集群中任何一个可用节点

基于客户端分配

采用哈希算法将Redis数据的key进行散列，通过hash函数，特定的key会映射到特定的Redis节点上

Redis实例彼此独立，相互无关联

不支持动态增删节点，每个客户端都需要更新调整

连接不能共享，当应用规模增大时，资源浪费制约优化

基于代理服务器分片

请求到一个代理组件，代理解析客户端的数据，并将请求转发至正确的节点

切换成本低

代理层多了一次转发，性能有所损耗

主从架构

一主多从，主负责写，并且将数据复制到其它的 slave 节点，从节点负责读。所有的读请求全部走从节点。支撑读高并发。

redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发

核心机制

异步方式复制

发送一个 PSYNC

full resynchronization 全量复制，master 会启动一个后台线程，开始生成一份 RDB 快照文件

将这个 RDB 发送给 slave，slave 会先写入本地磁盘，然后再从本地磁盘加载到内存中

master 会将内存中缓存的写命令发送到 slave

必须开启 master node 的持久化

在 master 宕机重启的时候数据是空的，然后可能一经过复制， slave node 的数据也丢了

从备份中挑选一份 rdb 去恢复 master，这样才能确保启动的时候，是有数据的

lave node 可以自动接管 master node，但也可能 sentinel 还没检测到 master failure，master node 就自动重启了，还是可能导致上面所有的 slave node 数据被清空

分区缺点

涉及多个key的操作通常不会被支持

不能对两个集合求交集

被存储到不同的Redis实例

同时操作多个key,则不能使用Redis事务.

数据处理会非常复杂

必须从不同的Redis实例和主机同时收集RDB / AOF文件

动态扩容或缩容可能非常复

Redis集群在运行时增加或者删除Redis节点，能做到最大程度对用户透明地数据再平衡，但其他一些客户端分区或者代理分区方法则不支持这种特性。

分布式锁

SETNX SET if Not eXists

当且仅当 key 不存在，将 key 的值设为 value。给定的 key 已经存在，则 SETNX 不做任何动作

解决 Redis 的并发竞争 Key

分布式锁（zookeeper 和 redis 都可以实现分布式锁）

每个客户端对某个方法加锁时，在zookeeper上的与该方法对应的指定节点的目录下，生成一个唯一的瞬时有序节点。判断是否获取锁的方式很简单，只需要判断有序节点中序号最小的一个。当释放锁的时候，只需将这个瞬时节点删除即可。同时，其可以避免服务宕机导致的锁无法释放，而产生的死锁问题。完成业务流程后，删除对应的子节点释放锁。

Redlock

互斥访问，即永远只有一个 client 能拿到锁

最终 client 都可能拿到锁，不会出现死锁的情况

只要大部分 Redis 节点存活就可以正常提供服务

优缺点

优点

读写性能优异

支持数据持久化

支持事务，所有操作都是原子性的，支持对几个操作合并后的原子性执行。

数据结构丰富

主从复制,进行读写分离

缺点