Redis持久化：RDB与AOF，五分钟快速掌握
Redis之所以强大，不仅因为它快，还因为它提供了数据持久化机制，防止服务器重启或宕机导致数据丢失。Redis提供了两种主要的持久化方式：RDB和AOF。以下是对于两种方式的解释
一、RDB（Redis Database）
是什么？
RDB就像是给Redis内存中的数据拍一张快照（Snapshot），并将这个二进制压缩文件保存到磁盘上。
如何工作？
- 手动触发： 执行
SAVE（阻塞）或BGSAVE（后台异步）命令。 - 自动触发： 在配置文件中设置规则，例如
save 900 1表示900秒内至少有1个key被改动，则自动触发BGSAVE。
优点
- 性能好： 父进程通过
fork子进程来持久化，主进程几乎不受影响，性能最大化。 - 文件紧凑： RDB文件是压缩后的二进制文件，体积小，非常适合灾难恢复和快速备份。
- 恢复快： 重启Redis时，加载巨大的RDB文件比回放AOF日志要快得多。
缺点
- 可能丢数据： 两次快照之间的数据改动，如果服务器宕机，则会丢失。
fork可能阻塞： 如果数据集非常大，fork子进程的过程可能会短暂阻塞主进程。
二、AOF（Append Only File）
是什么？
AOF更像是记录所有写操作命令的日志文件。每次执行一个写命令，这个命令就会以协议的格式追加到AOF文件的末尾。
如何工作？
- 记录日志： 服务器收到的每一个写命令（如
SET,SADD)都会写入缓冲区，再根据策略同步到磁盘的AOF文件。 - 重写机制（Rewrite）： AOF文件会越来越大。Redis提供了
BGREWRITEAOF命令，会fork一个子进程来创建一个新的、更小的AOF文件（通过合并冗余命令），替换旧的庞大数据。
优点
- durability更强： 你可以配置不同的同步策略（
appendfsync），最高可配置为每次写命令都同步到磁盘，最多丢失一秒的数据。 - 可读性强： AOF文件是纯文本格式，记录了所有操作命令，便于理解和手动修复。
缺点
- 文件更大： AOF文件通常比同数据集的RDB文件大。
- 恢复慢： 重启时需要重新执行所有AOF文件中的命令来恢复数据，过程比加载RDB慢。
- 对性能影响相对大： 如果配置为每次命令都同步（
always），会对性能有一定影响。
三、如何选择？RDB vs AOF
特性 | RDB | AOF |
持久化方式 | 定时快照 | 记录每次写命令 |
数据安全性 | 可能丢失最后一次快照后的数据 | 根据策略，最多丢失一秒数据 |
文件大小 | 小（二进制压缩） | 大（文本命令日志） |
恢复速度 | 快 | 慢 |
对性能影响 |
| 根据同步策略，影响可大可小 |
混合持久化（Redis 4.0+）
这是最好的选择！它结合了两者的优点。
工作原理： 在AOF重写时，子进程会先将当前内存的数据以RDB格式写入新的AOF文件开头，然后再将重写缓冲区的增量命令以AOF格式追加到文件。这样得到的AOF文件：
- 前半部分是RDB二进制数据，恢复速度快。
- 后半部分是增量AOF日志，数据更安全。
重启加载时，先加载RDB部分，再回放AOF日志，兼顾了速度和安全。
四、总结与建议
- 单纯做缓存，可以不用任何持久化。
- 如果既要求速度又要求安全？ 优先使用 混合持久化。
- 如果最关心数据安全，能容忍性能一点点下降？ 使用 AOF 并配置
appendfsync everysec每秒同步 - 如果追求最快恢复速度，能容忍分钟级数据丢失？ 使用 RDB。