Redis的持久化方式

Redis持久化RDB 持久化AOF持久化Redis 的高性能核心源于其将数据主要存储在内存中配合高效的内存管理机制和 IO 多路复用模型但内存的易失性是天然缺陷 一旦 Redis 进程异常退出、服务器重启或宕机内存中的数据会全部丢失。为解决内存数据持久化的问题Redis 设计了专门的持久化机制将内存中的数据以特定格式同步到硬盘磁盘保证数据在重启后能从磁盘文件中恢复兼顾高性能和数据安全性。Redis 支持两种核心且设计思路完全不同的持久化方式RDBRedis Database快照式以 “数据快照” 的形式在指定时间点将内存中的所有数据一次性写入磁盘AOFAppend Only File日志式以 “写操作日志” 的形式实时记录所有修改数据的命令重启时通过重放日志恢复数据。这两种方式可单独使用也可结合使用二者各有优劣需根据业务对性能损耗和数据安全性的要求选择。RDB 持久化RDBRedis 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持久化的完整流程RDB持久化通过创建子进程实现数据快照主进程继续处理请求子进程遍历内存数据生成临时RDB文件完成后原子替换旧文件并通知主进程更新状态整个过程利用写时复制(COW)机制确保数据一致性且不影响服务可用性当Redis需要进行内存快照时它会调用fork()系统函数创建一个子进程此时父子进程共享同一份内存数据但拥有独立的内存页表内存使用量几乎不增加子进程负责将内存数据结构遍历读取并序列化写入磁盘而父进程继续处理客户端请求并修改内存数据当父进程需要修改共享内存中的数据时操作系统会触发写时复制(COW)机制将被修改的内存页复制一份供父进程使用而子进程仍能看到fork时的原始数据状态子进程完成RDB文件写入后通过原子替换操作用新文件覆盖旧文件然后通知父进程持久化完成并退出整个过程中主进程仅因fork操作产生微秒级延迟之后能持续提供高性能服务从而巧妙解决了单线程既要服务请求又要进行文件IO的性能瓶颈问题。RDB 核心配置在 redis.conf 中 dir 用于指定 rdb 快照文件的位置在 redis.conf 中 dbfilenam 用于指定 rdb 快照文件的名称默认 dump.rdbRedis 启动时会先检查配置指定的 RDB 文件是否存在且完整若文件存在且无损坏Redis 会优先加载该二进制快照文件将数据一次性恢复到内存中若文件不存在、损坏或已禁用 RDB配置 save “”则跳过 RDB 加载流程。RDB 的优劣势RDB 的优势加载速度极快二进制格式无需解析命令直接还原数据结构且生成快照时由 fork 出的子进程完成磁盘 IO 操作Redis 主进程无阻塞对正常服务的性能影响小。RDB 的核心缺陷是数据持久性不足Redis 异常退出如进程崩溃、服务器宕机时会丢失最后一次 RDB 快照完成时刻到异常退出时刻之间的所有数据修改操作。因此需根据业务对数据丢失的容忍度合理配置 save 触发规则如缩短快照间隔、降低修改次数阈值将数据损失窗口控制在可接受范围若业务无法承受任何数据丢失需搭配 AOF 持久化方式使用。AOF持久化AOFAppend 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.aofRedis的AOFAppend Only File持久化通过记录所有写操作命令来实现数据持久化。当客户端发送写命令时Redis主进程先执行命令随后将命令以Redis协议格式追加到内存中的AOF缓冲区。此时命令暂存于内存待后续同步到磁盘从而避免每次操作都触发磁盘I/O提升性能。根据配置的 appendfsync 策略Redis会定期将缓冲区内容写入AOF文件若设置为always则每条命令立即强制同步到磁盘数据安全性最高但性能开销大若为everysec默认则每秒同步一次平衡安全与性能若为no则完全依赖操作系统调度性能最优但风险较高。写入磁盘时数据会先进入内核缓冲区再通过fsync系统调用确保真正落盘这一机制是AOF保障数据不丢失的核心。AOF持久化的完整流程当客户端执行写命令如 SET、INCR 等时Redis 主进程先执行命令随后将命令以文本格式的 Redis 协议追加到内存中的 AOF 缓冲区避免频繁磁盘 I/O。接着根据配置策略appendfsync 参数将缓冲区内容同步到磁盘always 模式每次写后立即同步数据零丢失但性能最低everysec默认每秒同步一次平衡安全与性能no 则依赖操作系统性能最高但风险大。随着时间推移AOF 文件可能因累积命令变得庞大影响恢复速度。当文件增长超过阈值如较上次重写后增大 100% 且超过 64MB或手动执行 BGREWRITEAOF 时主进程通过 fork 创建子进程。子进程扫描当前内存数据生成恢复相同状态所需的最简命令集写入临时 AOF 文件。同时主进程继续服务请求并将重写期间的新命令缓存到独立的重写缓冲区确保数据不丢失。子进程完成后主进程将缓冲区的命令追加到新文件并通过原子替换操作用新文件覆盖旧 AOF 文件整个过程不阻塞主线程。Redis 重启时若存在 AOF 文件会逐行读取并执行其中的命令重建内存数据。此外Redis 4.0 引入混合持久化重写时在新 AOF 文件头部写入 RDB 格式快照尾部追加增量命令兼顾恢复速度与完整性。这一流程通过“命令追加→策略同步→自动/手动重写→文件替换→重启加载”的闭环实现了数据高可靠性与性能的平衡尤其适用于对数据一致性敏感的场景其文本格式的日志文件还支持手动修复误操作成为 Redis 持久化的核心机制之一。AOF 的优劣势优势AOF 的数据持久性远高于 RDB默认采用每秒同步策略最多仅丢失 1 秒内的数据若配置为同步模式可实现数据零丢失。AOF 日志以文本协议格式存储可读性强当日志文件存在异常或错误命令时可通过手动编辑修正后再加载恢复灵活性更高。缺点相同数据集下AOF 文件体积通常远大于 RDB 文件Redis 重启时需逐命令重放恢复数据加载速度显著慢于 RDB。高并发写场景下AOF 文件会快速膨胀需定期执行重写操作而重写过程会带来额外的 CPU 消耗与磁盘 I/O 压力。