Redis教程

Redis高频面试

本文主要是介绍Redis高频面试,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

文章目录

  • 1.redis是什么?
  • 2.redis怎么使用?
  • 3.应用场景
    • String
    • List(双向链表)
    • hash(hashmap)
  • 4.为什么redis是单线程还这么快
  • 5.redis 也可以进行发布订阅消息吗?
  • 6.redis能否将数据持久化,如何实现?
    • RDB持久化原理
    • AOF持久化原理
  • 7.主从复制模式下,主挂了怎么办?
  • 8.哨兵模式实现原理?(2.8 版本或更高才有)
    • 1.三个定时监控任务
    • 2.主客观下线:
    • 3.选举出某一哨兵节点作为领导者来进行故障转移
  • 9.redis 集群
  • 10.缓存更新策略(即如何让缓存和 mysql 保持一致性)?
    • 10.1 key 过期清除(超时剔除)策略
    • 10.2 Redis 的内存淘汰策略
  • 12.如何防止缓存穿透?
  • 13.无底洞优化?
  • 14.雪崩优化

1.redis是什么?

redis 是 nosql(也是个巨大的 map) 单线程,但是可处理 1 秒 10w 的并发(数据都在内存中)

使用 java 对 redis 进行操作类似 jdbc 接口标准对 mysql,有各类实现他的实现类,我们常用的是 druid
其中对 redis,我们通常用 Jedis(也为我们提供了连接池 JedisPool)
在 redis 中,key 就是 byte,redis 的数据结构(value):
String,list,set,orderset,hash
每种数据结构对应不同的命令语句~

2.redis怎么使用?

先安装好 redis,然后运行,在 pom 文件中引入依赖,在要使用 redis 缓存的类的 mapper.xml 文件配置redis 的全限定名。引入 redis 的 redis.properties 文件(如果要更改配置就可以使用)

3.应用场景

String

  • 存储 json 类型对象
  • 计数器
  • 视频点赞等

List(双向链表)

  • 可以使用 redis 的 list 模拟队列,堆,栈
  • 朋友圈点赞(一条朋友圈内容语句,若干点赞语句)

hash(hashmap)

  • 保存对象
  • 分组

4.为什么redis是单线程还这么快

  1. .数据存于内存
  2. 用了多路复用 I/O
  3. 单线程

5.redis 也可以进行发布订阅消息吗?

可以(可以引出哨兵模式,就是因为每隔 2秒哨兵节点会发布对某节点的判断和自身的信息到某频道,每个哨兵订阅该频道获取其他哨兵节点和主从节点的信息,以达到哨兵间互相监控和对主从节点的监控)和很多专业的消息队列系统(例如 Kafka、RocketMQ)相比,Redis 的发布订阅略显粗糙,例如无法实现消息堆积和回溯。但胜在足够简单。

6.redis能否将数据持久化,如何实现?

能,将内存中的数据异步写入硬盘中,两种方式:RDB(默认)和 AOF

RDB持久化原理

通过 bgsave 命令触发,然后父进程执行 fork 操作创建子进程,子进程创建 RDB 文件,根据父进程内存生成临时快照文件,完成后对原有文件进行原子替换(定时一次性将所有数据进行快照生成一份副本存储在硬盘中)

优点:是一个紧凑压缩的二进制文件,Redis 加载 RDB 恢复数据远远快于 AOF的方式
缺点:由于每次生成 RDB 开销较大,非实时持久化

AOF持久化原理

开启后,Redis 每执行一个修改数据的命令,都会把这个命令添加到 AOF 文件中

优点:实时持久化
缺点:所以 AOF 文件体积逐渐变大,需要定期执行重写操作来降低文件体积,加载慢

7.主从复制模式下,主挂了怎么办?

哨兵模式(高可用)

何谓哨兵模式?就是通过哨兵节点进行自主监控主从节点以及其他哨兵节点,发现主节点故障时自主进行故障转移

8.哨兵模式实现原理?(2.8 版本或更高才有)

1.三个定时监控任务

  1. 每隔 10s,每个 S 节点(哨兵节点)会向主节点和从节点发送 info 命令获取最新的拓扑结构
  2. 每隔 2s,每个 S 节点会向某频道上发送该 S 节点对于主节点的判断以及当前 Sl 节点的信息
  3. 每隔 1s,每个 S 节点会向主节点、从节点、其余 S 节点发送一条 ping 命令做一次心跳检测(心跳检测机制),来确认这些节点当前是否可达

2.主客观下线:

  1. 主观下线:根据第三个定时任务对没有有效回复的节点做主观下线处理
  2. 客观下线:若主观下线的是主节点,会咨询其他 S 节点对该主节点的判断,超过半数,对该主节点做客观下线

3.选举出某一哨兵节点作为领导者来进行故障转移

选举方式:raft算法。每个 S 节点有一票同意权,哪个 S 节点做出主观下线的时候,就会询问其他 S 节点是否同意其为领导者。获得半数选票的则成为领导者。基本谁先做出客观下线,谁成为领导者。

9.redis 集群

  1. .Redis 集群内节点通过 ping/pong 消息实现节点通信,消息不但可以传播节点槽信息,还可以传播其他状态如:主从状态、节点故障等。因此故障发现也是通过消息传播机制实现的,主要环节包括:主观下线(pfail)和客观下线(fail)
  2. 主客观下线:
    2.1 集群中每个节点都会定期向其他节点发送 ping 消息,接收节点回复 pong 消息作为响应。
    如果通信一直失败,则发送节点会把接收节点标记为主观下线(pfail)状态
    2.2 客观下线:超过半数,对该主节点做客观下线
  3. 主节点选举出某一主节点作为领导者,来进行故障转移
  4. 故障转移(选举从节点作为新主节点)

10.缓存更新策略(即如何让缓存和 mysql 保持一致性)?

10.1 key 过期清除(超时剔除)策略

惰性过期(类比懒加载,这是懒过期):只有当访问一个 key 时,才会判断该 key是否已过期,过期则清除。
定期过期:每隔一定的时间,会扫描一定数量的数据库的 expires 字典中一定数量的 key,并清除其中已过期的 key。

10.2 Redis 的内存淘汰策略

Redis 的内存淘汰策略是指在 Redis 的用于缓存的内存不足时,怎么处理需要新写入且需要申请额外空间的数据。

noeviction:当内存不足以容纳新写入数据时,新写入操作会报错。
allkeys-lru:当内存不足以容纳新写入数据时,在键空间中,移除最近最少使用的 key。
allkeys-random:当内存不足以容纳新写入数据时,在键空间中,随机移除某个key。
volatile-lru:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,移除最近最少使用key。
volatile-random:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,随机移除某个 key。
volatile-ttl:当内存不足以容纳新写入数据时,在设置了过期时间的键空间中,有更早过期时间的 key 优先移除。

12.如何防止缓存穿透?

(缓存穿透指的是查询一个根本不存在的数据,缓存层不命中,又去查存储层,又不命中。但如果有大量这种查询不存在的数据的请求过来,会对存储层有较大压力)

穿透:将一份key作两次缓存,双缓存策略.

13.无底洞优化?

造成原因:redis 分布式越来越多,导致性能反而下降,因为键值分布到更多的节点上,所以无论是 Memcache 还是 Redis 的分布式,批量操作通常需要从不同节点上获取,相比于单机批量操作只涉及一次网络操作,分布式批量操作 会涉及多次网络时间。 即分布式过犹不及。

14.雪崩优化

如果缓存层由于某些原因不能提供服务,于是所有的请求都会达到存储层,存储
层的调用量会暴增,造成存储层也会级联宕机的情况。

雪崩:可以设置Redis cache(卡时)的过期时间,让缓存失效的时间尽量均匀

这篇关于Redis高频面试的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!