[TOC] 持久化就是把**内存的数据写到磁盘中**，防止服务宕机导致内存数据丢失。 Redis 支持两种方式的持久化，一种是`RDB`的方式，一种是`AOF`的方式。**前者会根据指定的规则定时将内存中的数据存储在硬盘上**，而**后者在每次执行完命令后将命令记录下来**。一般将两者结合使用。 ## RDB （Redis DataBase） `RDB`是 Redis 默认的持久化方案。，在指定的时间间隔内将内存中的数据集快照写入磁盘（在指定目录下生成一个`dump.rdb`二进制文件）。Redis 重启会加载`dump.rdb`文件恢复数据。 ~~~text save 3600 1 save 300 100 save 60 10000 ~~~ ### 执行过程 :-:  * 执行`BGSAVE`命令 * Redis 父进程判断当前**是否存在正在执行的子进程**，如果存在，`BGSAVE`命令直接返回。 * 父进程执行 `fork` 操作**创建子进程**，`fork` 操作过程中父进程会阻塞 * 父进程 `fork `完成后，**父进程继续接收并处理客户端的请求**，而子**进程开始将内存中的数据写进硬盘的临时文件**； * 当子进程写完所有数据后会**用该临时文件替换旧的 RDB 文件**。 Redis 启动时会读取 RDB 快照文件，将数据从硬盘载入内存。通过 RDB 方式的持久化，，一旦 Redis 异常退出，就会丢失最近一次持久化以后更改的数据。 ### 触发机制： 1. **手动触发**：执行`SAVE`或`BGSAVE`命令。`SAVE`命令执行快照的过程会阻塞所有客户端的请求，应避免在生产环境使用此命令。`BGSAVE`命令可以在后台异步进行快照操作，快照的同时服务器还可以继续响应客户端的请求，因此需要手动执行快照时推荐使用`BGSAVE`命令。 2. **被动触发**： * 根据配置规则进行自动快照，如`SAVE 100 10`，100 秒内至少有 10 个键被修改则进行快照。 * 如果从节点执行全量复制操作，主节点会自动执行 `BGSAVE` 生成 RDB 文件并发送给从节点。 * 默认情况下执行 `shutdown` 命令时，如果没有开启 AOF 持久化功能则自动执行`BGSAVE`。 * 执行 `flushall` 命令，也会触发我们的rdb规则！ ### 恢复数据 将 rdb 文件放在我们 redis 启动目录。redis 启动时自动检查 dump.rdb ### 优点 1. `Redis 加载 RDB 恢复数据远远快于 AOF 的方式`。 2. 使用**单独子进程来进行持久化**，主进程不会进行任何 IO 操作，**保证了 Redis 的高效性** ### 缺点 1.** RDB 方式数据无法做到实时持久化**，因为 `BGSAVE` 每次运行都要执行 `fork` 操作创建子进程，属于重量级操作，频繁执行成本比较高。 2. RDB 文件使用特定二进制格式保存，Redis 版本升级过程中有多个格式的 RDB 版本，**存在老版本 Redis 无法兼容新版 RDB 格式的问题**。 ## AOF（Append Only File） AOF（append only file）持久化：以独立日志的方式记录每次写命令，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件 但不可以改写文件，Redis 重启时会重新执行 AOF 文件中的命令达到恢复数据的目的。 AOF 的**主要作用是解决了数据持久化的实时性**，AOF 是 Redis 持久化的主流方式。 默认情况下 Redis 没有开启 AOF 方式的持久化，可以通过`appendonly`参数启用： ~~~ appendonly yes ~~~ 开启 AOF 方式持久化后每执行一条写命令，Redis 就会将该命令写进`aof_buf`缓冲区，AOF 缓冲区根据对应的策略向硬盘做同步操作。 默认情况下系统**每 30 秒**会执行一次同步操作。为了防止缓冲区数据丢失，可以在 Redis 写入 AOF 文件后主动要求系统将缓冲区数据同步到硬盘上。可以通过`appendfsync`参数设置同步的时机 ~~~ appendonly no # 默认是不开启aof模式的，默认是使用rdb方式持久化的，在大部分所有的情况下， rdb完全够用！ appendfilename "appendonly.aof" # 持久化的文件的名字 # appendfsync always # 每次修改都会 sync。消耗性能 appendfsync everysec # 每秒执行一次 sync，可能会丢失这1s的数据！ # appendfsync no # 不执行 sync，这个时候操作系统自己同步数据，速度最快！ ~~~ ### 执行过程 :-:  1. 所有的写入命令会追加到 AOF 缓冲区中 2. AOF 缓冲区根据对应的策略向硬盘同步 3. 随着 AOF 文件越来越大，需要定期对 AOF 文件进行重写，达到压缩文件体积的目的。AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程。 4. 当 Redis 服务器重启时，可以加载 AOF 文件进行数据恢复。 如果这个 aof 文件有错位，这时候 redis 是启动不起来的吗，我们需要修复这个aof文件 redis 给我们提供了一个工具 `redis-check-aof --fix` ### 优点 1. AOF 可以更好的保护数据不丢失，可以配置 AOF 每秒执行一次`fsync`操作，如果 Redis 进程挂掉，最多丢失 1 秒的数据 2. AOF 以 `append-only` 的模式写入，所以没有磁盘寻址的开销，写入性能非常高。 ### 缺点 1. 对于同一份文件 AOF 文件比 RDB 数据快照要大。 2. 数据恢复比较慢。