😀 这里写文章的前言： 我询问了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
