Redis 速度快，很大一部分原因是因为它所有的数据都存储在内存中。如果断电或者宕机，都会导致内存中的数据丢失。为了实现重启后数据不丢失，Redis 提供了两种持久化的方案，一种是 RDB 快照（Redis DataBase），一种是 AOF（Append Only File）。

RDB

RDB 是 Redis 默认的持久化方案。当满足一定条件的时候，会把当前内存中的数据写入磁盘，生成一个快照文件 dump.rdb。Redis 重启会通过加载 dump.rdb 文件恢复数据。

什么时候写入 rdb 文件？

RDB 触发

• 自动触发 a）配置规则触发。 redis.conf，SNAPSHOTTING，其中定义了触发把数据保存到磁盘的触发频率。如果不需要 RDB 方案，注释 save 或者配置成空字符串""。

save 900 1 # 900 秒内至少有一个 key 被修改（包括添加）
save 300 10 # 400 秒内至少有 10 个 key 被修改
save 60 10000 # 60 秒内至少有 10000 个 key 被修改

注意上面的配置是不冲突的，只要满足任意一个都会触发。 RDB 文件位置和目录：

# 文件路径，
dir ./
# 文件名称
dbfilename dump.rdb
# 是否是 LZF 压缩 rdb 文件
rdbcompression yes
# 开启数据校验
rdbchecksum yes

问题：为什么停止 Redis 服务的时候没有 save，重启数据还在

RDB 还有两种触发方式： b）shutdown 触发，保证服务器正常关闭。 c）flushall，RDB 文件是空的，没什么意义（删掉 dump.rdb 演示一下）。

• 手动触发 如果我们需要重启服务或者迁移数据，这个时候就需要手动触 RDB 快照保存。Redis提供了两条命令：

1. save save 在生成快照的时候会阻塞当前 Redis 服务器， Redis 不能处理其他命令。如果内存中的数据比较多，会造成 Redis 长时间的阻塞。生产环境不建议使用这个命令。

为了解决这个问题，Redis 提供了第二种方式。

1. bgsave

执行 bgsave 时，Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。 具体操作是 Redis 进程执行 fork 操作创建子进程（copy-on-write），RDB 持久化过程由子进程负责，完成后自动结束。它不会记录 fork 之后后续的命令。阻塞只发生在fork 阶段，一般时间很短。

用 lastsave 命令可以查看最近一次成功生成快照的时间。

RDB 数据的恢复（演示）

1. shutdown 持久化

添加键值

redis> set k1 1
redis> set k2 2
redis> set k3 3
redis> set k4 4
redis> set k5 5

停服务器，触发 save

redis> shutdown

备份 dump.rdb 文件

cp dump.rdb dump.rdb.bak

启动服务器

/usr/local/soft/redis-5.0.5/src/redis-server /usr/local/soft/redis-5.0.5/redis.conf

数据都在：

redis> keys *

1. 模拟数据丢失 模拟数据丢失，触发 save

redis> flushall

停服务器

redis> shutdown

启动服务器

/usr/local/soft/redis-5.0.5/src/redis-server /usr/local/soft/redis-5.0.5/redis.conf

啥都没有：

redis> keys *

1. 通过备份文件恢复数据 停服务器

redis> shutdown

重命名备份文件

mv dump.rdb.bak dump.rdb

启动服务器

/usr/local/soft/redis-5.0.5/src/redis-server /usr/local/soft/redis-5.0.5/redis.conf

查看数据

redis> keys *

RDB 文件的优势和劣势

一、优势

1. RDB 是一个非常紧凑(compact)的文件，它保存了 redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。
2. 生成 RDB 文件的时候，redis 主进程会 fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘 IO 操作。
3. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

二、劣势

1. RDB 方式数据没办法做到实时持久化/秒级持久化。因为 bgsave 每次运行都要执行 fork 操作创建子进程，频繁执行成本过高。
2. 在一定间隔时间做一次备份，所以如果 redis 意外 down 掉的话，就会丢失最后一次快照之后的所有修改（数据有丢失）。 如果数据相对来说比较重要，希望将损失降到最小，则可以使用 AOF 方式进行持久化。

AOF

Append Only File

AOF：Redis 默认不开启。AOF 采用日志的形式来记录每个写操作，并追加到文件AOF：Redis 默认不开启。AOF 采用日志的形式来记录每个写操作，并追加到文件。

Redis 重启时会根据日志文件的内容把写指令从前到后执行一次以完成数据的恢复工作。

AOF 配置

配置文件 redis.conf

# 开关
appendonly no
# 文件名
appendfilename "appendonly.aof"

问题：数据都是实时持久化到磁盘吗？ 由于操作系统的缓存机制，AOF 数据并没有真正地写入硬盘，而是进入了系统的硬盘缓存。什么时候把缓冲区的内容写入到 AOF 文件？

问题：文件越来越大，怎么办？ 由于 AOF 持久化是 Redis 不断将写命令记录到 AOF 文件中，随着 Redis 不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。

例如 set gupao 666，执行 1000 次，结果都是 gupao=666。

为了解决这个问题，Redis 新增了重写机制，当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。

可以使用命令 bgrewriteaof 来重写。

AOF 文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。

# 重写触发机制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

问题：重写过程中，AOF 文件被更改了怎么办？

另外有两个与 AOF 相关的参数：

AOF 数据恢复

重启 Redis 之后就会进行 AOF 文件的恢复。

AOF 优势与劣势

优点：

1. AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。

缺点：

1. 对于具有相同数据的的 Redis，AOF 文件通常会比 RDF 文件体积更大（RDB存的是数据快照）。
2. 虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。在高并发的情况下，RDB 比 AOF 具好更好的性能保证。