Redis持久化概述
Redis作为内存数据库，数据存储在内存中。为了保证数据在服务器重启或宕机时不丢失，Redis提供了两种持久化方案：
RDB（Redis Database）：定时生成内存快照
AOF（Append Only File）：记录写操作命令
混合持久化：结合RDB和AOF优势
Redis持久化核心机制
1. RDB(Redis Database)持久化
核心原理
- 快照机制：RDB通过生成内存数据快照（Snapshot）来持久化数据。快照是某个时间点的完整数据副本，保存为二进制文件（默认文件名为dump.rdb）。
- 触发条件：
- 手动触发：通过 SAVE（阻塞主线程）或 BGSAVE（后台异步）命令生成快照。
- 自动触发：根据配置的规则（如 save <seconds> <changes>）自动执行BGSAVE，例如：
save 900 1 # 900秒内至少1次修改则触发
save 300 10 # 300秒内至少10次修改
save 60 10000 # 60秒内至少10000次修改实现细节
- 写时复制（Copy-On-Write，COW）：
- BGSAVE通过fork子进程生成快照，父进程继续处理请求。
- 子进程共享父进程的内存页表，当父进程修改数据时，会触发COW机制，复制被修改的内存页，保证子进程的数据一致性。
- 文件格式：
- RDB文件是压缩的二进制文件，包含键值对、过期时间等信息。
优点
- 高性能：二进制文件体积小，加载速度快（适合大规模数据恢复）。
- 容灾备份：快照文件可定期备份到远程服务器。
- 低资源占用：生成快照时主进程仅fork一次，对性能影响较小。
缺点
- 数据丢失风险：两次快照之间的数据可能丢失（取决于触发频率）。
- 大数据量时fork可能阻塞：数据量过大时，fork子进程可能耗时较长（内存越大越明显）。
适用场景
- 需要快速恢复数据（如灾备）。
- 允许分钟级数据丢失。
-
对磁盘 I/O 和性能敏感的场景。
2. AOF(Append-Only-File)持久化
核心原理
- 日志追加：AOF记录所有修改数据的命令（以Redis协议追加到文件末尾），重启时通过重放命令恢复数据。
- 文件同步策略（通过appendfsync配置）：
- no：由操作系统决定何时同步（性能最高，但可能丢失较多数据）。
- everysec：每秒同步一次（默认，最多丢失1秒数据）。
- always：每次写命令都同步（最安全，但性能最差）。
实现细节
- AOF重写（Rewrite）：
- 解决 AOF 文件膨胀问题，将当前内存数据生成等效的最小命令集，覆盖旧文件。
- 触发方式：
- 手动触发：通过 BGREWRITEAOF 命令。
- 自动触发：根据
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size配置（如当 AOF 文件增长超过 100% 且大小超过 64MB 时触发）。
优点
- 数据安全性高：根据同步策略，最多丢失1秒（甚至零）数据。
- 可读性强：AOF 文件是文本格式，便于人工分析或修复。
- 灵活控制：支持动态调整同步策略。
缺点
- 文件体积大：AOF 文件通常比 RDB 大。
- 恢复速度慢：重放所有命令恢复数据，耗时长。
- 写入压力大：高并发下频繁同步可能影响性能。
适用场景
- 对数据完整性要求高（如金融场景）。
- 允许牺牲部分性能换取更高可靠性。
3. RDB VS AOF 对比
4. 混合持久化（Redis 4.0+）
Redis 4.0引入了RDB-AOF混合模式，结合两者优势：
- 开启方式：设置
aof-use-rdb-preamble yes。 - 实现原理：
-
AOF 文件由两部分组成：
-
RDB 格式的前半部分：保存快照时的数据。
-
AOF 格式的后半部分：保存快照后的增量命令。
-
-
-
优点：快速加载RDB部分，再重放少量AOF命令，兼顾恢复速度和数据安全。
