Redis简历话术
本专栏只总结最重要的八股，简历对应的
简历话术：
Redis:熟悉Redis基本使⽤、常⻅缓存读写策略、⽣产问题及持久化、内存管理、集群、分布式锁
1.常见缓存读写策略
1.1 Cache Aside（旁路缓存）策略
写
先更新数据库中的数据，再删除缓存中的数据。
读
如果读取的数据命中了缓存，则直接返回数据 如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入到缓存，并且返回给用户。
1.2 Read/Write Through（读穿 / 写穿）策略
写
应用程序的“写”请求，必须直接发送到缓存组件。缓存组件负责同步： 缓存组件（或一个智能的客户端库）接收到写请求后，会原子性地、同步地执行以下两个操作：a. 更新数据库： 将新的数据写入底层数据库。b. 更新缓存： 将新的数据写入自身的缓存。 应用要直接写缓存，但缓存系统会保证数据库也随之更新。 这正是 Write-Through 模式得名的原因——写请求“穿透”缓存，直达数据库。
读
应用直接读缓存。缓存命中则返回；未命中则由缓存组件负责从数据库加载并写入自身，然后返回。
| 特性 | 读穿 / 写穿（封装） | 旁路缓存（应用自己处理） |
|---|---|---|
| 核心哲学 | 缓存是数据主入口，对应用透明，是一种封装 | 缓存是数据库的辅助旁路，应用==显式管理== |
| 读流程 | 缓存未命中时，缓存自身从DB加载 应用 -> 缓存。 | 存未命中时，应用从DB加载并回填 |
| 写流程 | 缓存自身同步更新DB | 应用 -> 数据库，然后应用使缓存失效 |
| 性能 | 写操作延迟较高（需同步写DB） | 写操作延迟较低（因为可以做优化，比如合并多个缓存失效操作，异步更新DB删除缓存） |
| 适用场景 | 一致性要求高、希望应用逻辑简单的场景 | 需要最高性能、能接受短暂不一致的通用场景 |
1.3 Write Back（写回）策略
写
只更新缓存，将缓存数据设置为脏的，不更新数据库。对于数据库，批量异步更新
读
如果读取的数据命中了缓存，则直接返回数据 如果读取的数据没有命中缓存，则从数据库中读取数据，然后将数据写入到缓存（标记干净），并且返回给用户。
2.Redis生产问题和解决方案（缓存雪崩 缓存穿透 缓存击穿（热点key问题）)
这些问题都是害怕数据库出问题，而不是说缓存本身。数据库和缓存性能差距巨大，QPS相差1-2个数量级。
- 缓存穿透是查询数据库中不存在的数据，缓存空对象即使查询不到，也缓存一个空值（如""或null）并设置一个较短的过期时间。布隆过滤器在缓存之前加一层布隆过滤器，用于快速判断某个key是否一定不存在于数据库中。如果布隆过滤器说不存在，则直接返回，避免查询数据库。
- 缓存雪崩是大量的缓存数据同时过期失效（错开过期时间），或者缓存服务整体宕机（高可用集群），导致所有原本应该访问这些缓存的请求，瞬间都涌向了后端数据库（如MySQL）。
- 缓存击穿（热点Key问题） 一个热点key在缓存过期的瞬间，大量请求同时涌入，击穿缓存，直接访问数据库，互斥锁（大量打到数据库的请求让第一个拿到锁，其他的拿不到锁就休眠不去打到数据库重新尝试拿缓存，拿不到缓存就尝试拿锁，拿不到锁就再等会继续，直到第一个写入缓存。当然也要释放锁），热点数据永不过期（用逻辑过期），
3. 持久化机制
3.1 AOF持久化
AOF的写入分为两个步骤：
命令追加（Append to Buffer）：
主线程执行完写命令后，会将该命令以协议格式追加到内存中的AOF缓冲区（aof_buf）。 这个操作是在主线程中完成的！
同步磁盘（Sync to Disk）：
根据 appendfsync 的配置，决定如何将缓冲区中的数据写入并同步到磁盘的AOF文件中。fsync()是一个系统调用，能立马将数据同步到硬盘，而不是像write一样先到内核缓冲区。 这就是 everysec, always, no 策略发挥作用的地方。
no策略意味着把何时写入磁盘交给了操作系统。
AOF重写：Redis 为了解决 AOF 文件膨胀问题
- 不读取旧 AOF 文件，而是直接读取当前内存中的数据库状态，生成等价的最小写命令集（例如将多个操作合并为最终结果的 SET/HSET 等）
- 重写过程由子进程（AOF重写时，要读取所有缓存的键值对，所以要耗时，故开子进程,写入 AOF 日志的操作是在主进程完成的，因为它写入的内容不多一般不太影响命令的操作。)在后台执行，避免阻塞主进程处理请求
- 完成后用新 AOF 文件原子替换旧文件，并继续追加后续命令。
存在问题，如果子进程生成AOF文件的时候，一部分处理过的生成了对应AOF日志的键值又被修改了。最后就会丢失这个修改。 如何解决？ 利用写时复制”和“AOF重写缓冲区本文只有最高频主要，具体点击可看
AOF记录的是操作命令。如果要做恢复。得有执行命令的过程。 如果用RDB，那么直接把他读入内存就可以。
3.2 RDB快照
它会在指定的时间间隔内，将内存中的数据以二进制文件的形式保存到硬盘。 恢复速度快，但是可能丢失数据
3.3 RDB和AOF合体
混合使用AOF日志和内存快照（混合持久化） 混合持久化工作在AOF日志重写过程，也就是说原来的AOF重写，子进程写入的是AOF日志，而现在写入的是RDB快照的全量数据，之后再写入AOF格式的增量数据（将重写缓冲区中的内容写入）
兼有两者优点
4. 内存管理
4.1 过期删除（惰性删除+定期删除）
- 惰性：客户端访问键 → Redis检查过期字典 → 如果过期 → 立即删除 → 返回空值
- 定期：定时任务启动 → 随机抽样键 → 检查过期 → 删除过期键 → 控制执行时间（避免循环过度出现线程卡死）→ 判断本轮过期key比例→ 如果超过则返回随机抽样那个步骤
4.2 内存淘汰
当超过配置的maxmemory，会触发内存淘汰机制
不进行数据淘汰（Redis3.0后默认）
当超过maxmemory，直接返回错误，不再提供服务。
进行数据淘汰（可配置策略）
在设置了过期时间的数据中进行淘汰 volatile
- volatile-random - 随机淘汰
- volatile-ttl - 优先淘汰最早过期
- volatile-lru - 淘汰最久未使用
- volatile-lfu - 淘汰最少使用
在所有数据范围内淘汰 allkeys
- allkeys-random 随机
- allkeys-lru 最久未使用
- allkeys-lfu 最少使用
5. 集群（实现高可用）
5.1 主从复制
一个主节点负责写，多个从节点负责读。
5.2 哨兵模式
在主从复制的基础上，增加了哨兵进程来监控主从节点的健康状态。当主节点宕机时，哨兵能自动将一个从节点提升为新的主节点，并让其他从节点指向新的主节点。
5.3 切片集群模式（cluster集群）
有主从，无哨兵，分片 Redis Cluster是从Redis3.0版本开始，官方提供的一种实现切片集群的方案。
高可用 (High Availability): 每个主节点都应至少有一个 从节点 (Slave)。（一个集群最少需要 3 个主节点 才能保证高可用（故障转移需要多数派同意）。当主节点发生故障时，其从节点会自动晋升为新的主节点，继续提供服务。
Redis 分片集群（Cluster）模式中，没有也不需要独立的哨兵（Sentinel）进程。Redis切片集群，持续地与其他节点进行通信，互相监控健康状态。当需要判断一个主节点是否失效时，集群中的其他主节点会共同参与投票。
分片 (Sharding): 数据被自动分割到多个 主节点 (Master) 上，每个主节点负责整个集群数据的一个子集。 哈希槽 (Hash Slot): 集群共有 16384 个槽（固定使用16384（16K）个哈希槽（Hash Slot），并且这个数字是硬编码的）。每个键通过 CRC16 校验后对 16384 取模来决定放入哪个槽。槽再被分配到具体的某个主节点上。 增减节点时，只需在节点间迁移槽位，无需对所有数据重新哈希
哈希槽怎么映射到具体的主节点中？
- 平均分配。默认均分
- 手动分配
6. 分布式锁
针对面试，整理简历上写的每行技术点+对应完整话术和扩展点，快速速成
