与面试相关的redis

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

发布订阅

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