北京JAVA基础面试30天打卡05
一、Redis 的持久化机制有哪些？**
Redis 提供两种主要的持久化机制：
✅ RDB（Redis DataBase）快照持久化
- 定期将 Redis 中的数据以“快照”的形式写入磁盘（生成
.rdb文件）。 - 启动 Redis 时会加载
.rdb文件恢复数据。 - 触发方式：
- 手动执行
SAVE或BGSAVE命令。 - 根据配置（如
save 900 1）定期自动触发。
- 手动执行
- 优点：
- 恢复速度快，占用磁盘小。
- 缺点：
- 异常宕机可能会丢失最近修改的数据（非实时）。
✅ AOF（Append Only File）追加日志持久化
- 将每次写操作（如
SET,HSET,INCR等）以日志方式记录到.aof文件中。 - 启动 Redis 时重放
.aof日志以恢复数据。 - 刷新策略：
always：每次操作都写入磁盘，最安全但性能差。everysec（默认）：每秒写一次，性能与安全的折中。no：完全由操作系统控制刷盘时机。
- 优点：
- 持久化更可靠，可恢复最近的数据。
- 缺点：
- 文件比 RDB 大，恢复速度慢。
✅ 混合持久化（Redis 4.0+）
- 同时使用 AOF 和 RDB 优势。
- RDB 保存大部分数据，AOF 记录最后的增量变化。
- 适用于既要快速恢复也要数据尽量完整的场景。
总结一张图（文字版）：
| 机制类型 | 描述 | 优缺点 |
|---|---|---|
| RDB | 快照形式保存数据到硬盘 | 快速恢复、可能丢数据 |
| AOF | 每次写操作记录日志 | 数据更完整、文件大 |
| 主从复制 | 主节点写、从节点读 | 高可用、读写分离 |
| 过期删除 | 定时 / 惰性 / 定期 | 兼顾性能和内存释放 |
🏢 实际大厂方案举例（简化版）
| 公司/场景 | 持久化策略 | 说明 |
|---|---|---|
| 阿里巴巴 | 关闭持久化（缓存场景） | Redis 宕机自动重建缓存，不做持久化 |
| 字节跳动 | AOF everysec + RDB 混合 | 用于关键服务，定期冷备 RDB |
| 京东 | 主从复制 + AOF + 异地灾备 | 高可用架构，主机持久化 AOF，从节点只读 |
| 腾讯云 Redis | 默认开启 AOF everysec + RDB | 提供用户可选关闭 |
| 美团 | 自研容器化 Redis + AOF everysec | 使用混合持久化恢复用户 session 数据 |
🧠 总结建议
| 需求类型 | 推荐持久化方案 | 理由 |
|---|---|---|
| 缓存为主、能容忍丢失 | 不持久化 | 最佳性能 |
| 数据重要、不能丢 | AOF everysec + RDB | 高可靠性恢复 |
| 启动速度要求高 | RDB + 备份定期触发 | 恢复快，节省磁盘 |
| 高可用架构 | 主从 + 哨兵 + 持久化 | 容灾能力强 |
二、Redis 主从复制的实现原理
Redis 主从复制（Replication）用于实现读写分离、数据备份和高可用架构。
实现流程：
- 从节点发送 SYNC 请求：
- 启动后通过配置或命令（如
SLAVEOF）向主节点发起复制请求。
- 启动后通过配置或命令（如
- 主节点执行 RDB 快照：
- 执行
BGSAVE生成 RDB 快照，将数据发送给从节点。
- 执行
- 从节点加载快照：
- 清空原有数据后加载主节点传过来的 RDB 文件。
- 复制增量写命令：
- 主节点在 RDB 传输完后将期间的写命令缓存在
replication backlog buffer中，一并发给从节点。 - 此后主节点每执行一次写命令就同步给所有从节点。
- 主节点在 RDB 传输完后将期间的写命令缓存在
特点：
- 异步复制： 默认是异步，但 Redis 6.0 起支持部分同步机制。
- 断线重连：
- 若断线，从节点尝试“部分重同步”（基于
runId和offset）。 - 不行时才进行完整的 RDB + AOF 同步。
- 若断线，从节点尝试“部分重同步”（基于
三、 Redis 数据过期后的删除策略
Redis 为了释放内存，提供了三种删除过期 key 的策略：
✅ 定时删除（主动删除）
- 给 key 设置了过期时间后，Redis 会为其设置一个定时器，到时间自动删除。
- 优点： 内存及时释放。
- 缺点： 会影响 CPU 性能（每个 key 都定时检查代价高）。
✅ 惰性删除（被动删除）
- 客户端访问某个 key 时，Redis 会先检查是否过期，若过期就删除。
- 优点： 不浪费 CPU。
- 缺点： 若没有访问，过期 key 会长期占内存。
✅ 定期删除（定期抽样删除）
- Redis 会周期性（默认 100ms）随机抽取部分 key 进行过期检查并删除。
- 优点： 兼顾性能与内存控制。
- 缺点： 某些 key 可能在长时间内未被检查到，造成内存浪费。
四、淘汰策略
策略名称 策略说明 适用场景
noeviction 不淘汰，直接拒绝写入操作（默认策略） 数据不能丢的场景（如金融）
allkeys-lru 所有键中，淘汰最久未使用的（Least Recently Used） 通用缓存、Web缓存
volatile-lru 只在设置了过期时间（TTL）的键中，淘汰最久未使用的 局部热数据缓存
allkeys-random 所有键中随机淘汰 对访问频率无强依赖的缓存
volatile-random 只在设置了过期时间的键中随机淘汰 弱一致性、低优先级缓存
volatile-ttl 只淘汰 TTL 剩余时间最短的 key（即快要过期的 key） 想优先保留长期 key
五、LUR/随机策略内部机制
✅ allkeys-lru 是最常用的策略
Redis 内部维护了访问信息（LRU/approximate LRU），采用 采样+近似LRU算法：
抽样 5 个 key（默认），比较其访问时间，淘汰最久未使用的。
可以通过 maxmemory-samples 设置样本数（越大越精准，但耗 CPU）：
六、实践建议
💡 推荐策略组合：
场景 推荐配置
通用缓存 allkeys-lru（经典）
只缓存部分热点数据 volatile-lru + 设置 TTL
极限性能下，快速释放空间 allkeys-random
数据敏感/不能自动淘汰 noeviction（程序层判断+降级处理）