与面试相关的redis

2023-9-7|2023-9-9
NotionNext
NotionNext
type
status
date
slug
summary
tags
category
icon
password
😀
这里写文章的前言: 我询问了chatGPT如果是针对面试,redis相关的我应该掌握哪些内容,它给出了回复,接下来我要针对他给出的几个方面进行一下整理。
 

📝 redis的知识点

数据结构及其特性,用途和操作方法

数据结构
底层
特性
用途
操作方法
String
SDS
简单的kv
缓存,计数器,分布式锁
set key value
List
双端链表/压缩链表
key v1,v2 有序,可重复
消息队列,评论列表,时间线等有序数据
lpush/rpush key value value
Hash
压缩链表/字典
key key,value[key,value…]
用户,商品信息等对象,更接近java里的对象
hset key key1 value1
Set
字典
key v1,v2… 无序,唯一
标签,用户id集合等,方便去重
sadd key v1 v2
ZSet
压缩列表/跳表
排序,权重
排行榜,带权重的消息队列等需要排序的场合
zadd key score v1 score v2

持久化

特性
rdb
aof
存储类型
二进制文件
操作命令日志文件
命令
SAVE # 阻塞服务器进程,保存快照 BGSAVE # 在后台异步保存快照
bgrewriteaof 重写
配置
save 900 1 # 900秒内至少有1个键被修改时自动保存RDB快照 save 300 10 # 300秒内至少有10个键被修改时自动保存RDB快照 save 60 10000 # 60秒内至少有10000个键被修改时自动保存RDB快照 dbfilename dump.rdb # RDB文件名 dir /path/to/your/backup/directory # RDB文件保存目录
appendonly yes # 启用AOF持久化 appendfsync always # 每个写操作都同步到磁盘 appendfilename "appendonly.aof" # AOF文件名 dir /path/to/your/appendonly/directory # AOF文件保存目录
是否主线程
save主线程 bgsave子线程
子线程
优点
数据快照,恢复速度块
文件大,恢复速度慢
缺点
会丢失最后一次快照后的数据
安全性高,高可用
ㅤ
ㅤ
ㅤ

高可用

特性
主从
哨兵
集群
说明
一主多从
一主多从+哨兵监控主节点
多主多从+hash槽 数据分片
设置
slaveof
通过sentinel.conf配置
CLUSTER MEET
故障转移
不支持
支持
支持
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ
ㅤ

分布式锁

 
特性
描述
获取锁
使用SETNX命令(Set if Not eXists)来在Redis中设置一个键值对作为锁,如果该键不存在,则设置成功,表示获取到锁。
锁的持有时间
可以为锁设置一个超时时间,以防止锁被持有太久而导致死锁。可以使用EXPIRE命令来为锁设置过期时间。
释放锁
使用DEL命令来删除锁键来释放锁。
避免竞态条件
在设置锁时,可以为锁键设置一个唯一的标识(例如,使用UUID),以确保只有持有锁的一方才能释放它。
处理死锁
可以使用Lua脚本来原子性地释放锁,避免在解锁过程中由于某些原因导致死锁。
自动续期
使用SET命令和EX选项来为锁键设置超时时间,并在持有锁期间定期更新超时时间,以避免锁过期。
并发控制
可以使用WATCH和MULTI/EXEC命令组合来实现乐观锁,以确保在锁被释放之前,其他客户端无法获取锁。
锁粒度
可以实现多种锁粒度,例如全局锁和分布式资源锁,以满足不同的应用场景需求。
附上什么情况下会发生死锁:
在使用Redis来实现分布式锁时,死锁通常是由于不正确的锁的使用和释放方式引起的。以下是一些可能导致死锁的情况:
  1. 未释放锁:如果一个客户端成功获取锁但在后续操作中没有正确释放锁,那么其他客户端将永远无法获取这个锁,从而导致死锁。
  1. 锁的超时时间不合理:如果设置锁的超时时间太短,那么在锁还有效的情况下,其他客户端可能会尝试获取锁,导致死锁。另一方面,如果锁的超时时间太长,那么即使一个客户端意外宕机或崩溃,其他客户端也无法获得锁,同样可能导致死锁。
  1. 并发更新:如果多个客户端同时尝试获取和更新锁的状态,可能会导致竞争条件,从而破坏了锁的正确性,进而导致死锁。
  1. 网络问题:如果由于网络问题或Redis集群分区,某个客户端无法及时获得锁释放的消息,它可能会陷入等待锁释放的状态,导致死锁。
  1. 复杂的锁协议:一些复杂的锁协议,如读写锁或带有多个状态的锁,可能更容易出现问题,需要更谨慎的实现和测试,以防止死锁。

发布订阅

PUBLISH channel “消息内容”
SUBSCRIBE channel

性能优化

安全性

数据分片

缓存策略

键过期删除策略

Redis的过期删除策略就是:惰性删除和定期删除两种策略配合使用。
惰性删除:Redis的惰性删除策略由 db.c/expireIfNeeded 函数实现,所有键读写命令执行之前都会调用 expireIfNeeded 函数对其进行检查,如果过期,则删除该键,然后执行键不存在的操作;未过期则不作操作,继续执行原有的命令。
定期删除:由redis.c/activeExpireCycle 函数实现,函数以一定的频率运行,每次运行时,都从一定数量的数据库中取出一定数量的随机键进行检查,并删除其中的过期键。
注意:并不是一次运行就检查所有的库,所有的键,而是随机检查一定数量的键。
定期删除函数的运行频率,在Redis2.6版本中,规定每秒运行10次,大概100ms运行一次。在Redis2.8版本后,可以通过修改配置文件redis.conf 的 hz 选项来调整这个次数。

内存淘汰策略

在配置文件redis.conf 中,可以通过参数 maxmemory <bytes> 来设定最大内存
当现有内存大于 maxmemory 时,便会触发redis主动淘汰内存方式,通过设置 maxmemory-policy ,有如下几种淘汰方式:
1)volatile-lru   利用LRU算法移除设置过过期时间的key (LRU:最近使用 Least Recently Used ) 。
2)allkeys-lru   利用LRU算法移除任何key (和上一个相比,删除的key包括设置过期时间和不设置过期时间的)。通常使用该方式。
3)volatile-random 移除设置过过期时间的随机key 。
4)allkeys-random  无差别的随机移除。
5)volatile-ttl   移除即将过期的key(minor TTL)
6)noeviction 不移除任何key,只是返回一个写错误 ,默认选项,一般不会选用。

🤗 总结归纳

掌握这些高级Redis知识点将使你在面试中展现出对Redis的深刻理解和实际应用经验。同时,还应准备答案,以解释你在实际项目中如何使用Redis来解决特定的问题和挑战。

📎 参考文章

  • chatGPT和claude2
读书记录AbstractQueuedSynchronizer