Redis持久化
- [RDB 持久化](#RDB 持久化)
- AOF持久化
Redis 的高性能核心源于其将数据主要存储在内存中（配合高效的内存管理机制和 IO 多路复用模型），但内存的易失性是天然缺陷 ，一旦 Redis 进程异常退出、服务器重启或宕机，内存中的数据会全部丢失。为解决内存数据持久化的问题，Redis 设计了专门的持久化机制：将内存中的数据以特定格式同步到硬盘（磁盘），保证数据在重启后能从磁盘文件中恢复，兼顾高性能和数据安全性。
Redis 支持两种核心且设计思路完全不同的持久化方式：
RDB（Redis Database，快照式）：以 "数据快照" 的形式，在指定时间点将内存中的所有数据一次性写入磁盘；
AOF（Append Only File，日志式）：以 "写操作日志" 的形式，实时记录所有修改数据的命令，重启时通过重放日志恢复数据。
这两种方式可单独使用，也可结合使用，二者各有优劣，需根据业务对性能损耗和数据安全性的要求选择。
RDB 持久化
RDB（Redis Database）是 Redis 默认启用的持久化方式，核心原理是：Redis 会监控预设的快照触发条件，当条件满足时，会 fork 一个子进程，由子进程将内存中的整个数据集以二进制形式完整写入临时文件，写入完成后替换原有快照文件（默认文件名 dump.rdb），最终同步到磁盘。
RDB 触发方式
通过 redis.conf 配置文件中的 save 规则触发：
多个 save 规则是「或」的关系，满足任意一个就会触发，若想关闭自动触发，只需配置save ""（空字符串）。
save 900 1 表示15分钟（900秒钟）内至少1个键被更改则进行快照，save 300 10 表示5分钟（300秒）内至少10个键被更改则进行快照，save 60 10000 表示60秒内至少10000个键被更改则进行快照。
RDB 核心配置
在 redis.conf 中 dir 用于指定 rdb 快照文件的位置
在 redis.conf 中 dbfilenam 用于指定 rdb 快照文件的名称（默认 dump.rdb）
Redis 启动时，会先检查配置指定的 RDB 文件是否存在且完整，若文件存在且无损坏，Redis 会优先加载该二进制快照文件，将数据一次性恢复到内存中；若文件不存在、损坏或已禁用 RDB（配置 save ""），则跳过 RDB 加载流程。
RDB 的优劣势
RDB 的优势：加载速度极快（二进制格式无需解析命令，直接还原数据结构），且生成快照时由 fork 出的子进程完成磁盘 IO 操作，Redis 主进程无阻塞，对正常服务的性能影响小。
RDB 的核心缺陷是数据持久性不足：Redis 异常退出（如进程崩溃、服务器宕机）时，会丢失最后一次 RDB 快照完成时刻到异常退出时刻之间的所有数据修改操作。因此需根据业务对数据丢失的容忍度合理配置 save 触发规则（如缩短快照间隔、降低修改次数阈值），将数据损失窗口控制在可接受范围；若业务无法承受任何数据丢失，需搭配 AOF 持久化方式使用。
AOF持久化
AOF（Append Only File）是 Redis 提供的日志式持久化方式，核心原理是：Redis 将所有会修改数据集的写操作命令（如 SET、HSET、INCR 等，读操作如 GET、HGET 不记录），以 Redis 协议格式的文本指令追加写入到 AOF 日志文件中；当 Redis 重启时，会忽略原有内存数据，通过从头到尾逐条执行 AOF 文件中的所有写命令，还原出重启前的完整数据集。
Redis 启动时，若同时开启 RDB 和 AOF，会优先加载 AOF 文件（数据更完整）
AOF 核心配置
默认情况下 Redis 没有开启 AOF 方式的持久化，通过 appendonly 参数开启，配置项：appendonly yes
存储目录与文件名：AOF 文件的存储目录与 RDB 共用 dir 配置项，默认文件名是 appendonly.aof，可通过 appendfilename 参数修改（如 appendfilename appendonly.aof）
AOF 的优劣势
优势：AOF 的数据持久性远高于 RDB，默认采用每秒同步策略，最多仅丢失 1 秒内的数据；若配置为同步模式，可实现数据零丢失。AOF 日志以文本协议格式存储，可读性强，当日志文件存在异常或错误命令时，可通过手动编辑修正后再加载恢复，灵活性更高。
缺点：相同数据集下，AOF 文件体积通常远大于 RDB 文件；Redis 重启时需逐命令重放恢复数据，加载速度显著慢于 RDB。高并发写场景下，AOF 文件会快速膨胀，需定期执行重写操作，而重写过程会带来额外的 CPU 消耗与磁盘 I/O 压力。