😀 这里写文章的前言: 我询问了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来实现分布式锁时,死锁通常是由于不正确的锁的使用和释放方式引起的。以下是一些可能导致死锁的情况:
- 未释放锁:如果一个客户端成功获取锁但在后续操作中没有正确释放锁,那么其他客户端将永远无法获取这个锁,从而导致死锁。
- 锁的超时时间不合理:如果设置锁的超时时间太短,那么在锁还有效的情况下,其他客户端可能会尝试获取锁,导致死锁。另一方面,如果锁的超时时间太长,那么即使一个客户端意外宕机或崩溃,其他客户端也无法获得锁,同样可能导致死锁。
- 并发更新:如果多个客户端同时尝试获取和更新锁的状态,可能会导致竞争条件,从而破坏了锁的正确性,进而导致死锁。
- 网络问题:如果由于网络问题或Redis集群分区,某个客户端无法及时获得锁释放的消息,它可能会陷入等待锁释放的状态,导致死锁。
- 复杂的锁协议:一些复杂的锁协议,如读写锁或带有多个状态的锁,可能更容易出现问题,需要更谨慎的实现和测试,以防止死锁。
发布订阅
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 来设定最大内存
当现有内存大于 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