Redis 是将数据存储在内存中的，如果出现断电或系统故障的时候数据就会存在丢失的现象，Redis通过将数据持久化到硬盘中来避免这个问题的出现，我们今天就来学习下 Redis 持久化。
Redis 持久化触发条件
- 手动触发
- save
- bgsave
- 自动触发
- 配置策略
- 系统命令
- flushdb
- exit
save 和 bgsave 的区别
Redis 是单线程操作的，当执行 save 命令时会阻塞住线程，阻塞时长根据数据量变化，这样就会造成 Redis 无法响应其他命令。而调用 bgsave 命令 Redis 会调用 fork 来创建一个子进程，然后子进程负责进行持久化操作，而主进程继续处理命令。
配置策略
Redis 在配置文件中设置了几个策略:
save 900 1 # 900秒内（15分钟）,更改了1个以上的键
save 300 10 # 30秒内（5分钟）改变了10个以上的键
save 60 10000 # 60秒内改变了10000个以上的键
当满足以上任意条件时就能触发。
Redis 持久化选项
Redis 提供了两种持久化方式将数据存储到硬盘中。
一种方式叫做 RDB（Redis DataBase），在指定的时间间隔内，执行指定次数的写操作，就会触发将内存中的数据写入到硬盘中(即在指定目录下生成一个 dump.rdb 文件)。它是 Redis 默认的持久化方式。
另一种方式叫做 AOF(Append Only File)，在指定的时间间隔内，执行指定次数的写操作，就会触发将写指令命令追加到硬盘中的日志文件里。
简单来说，前者是将所有数据都保存起来，在之后全量恢复。而后者是将指令以日志形式存储，在之后通过重新执行指令来还原数据。
RDB
RDB 持久化配置
以文本形式打开 redis.conf 文件，搜索关键字 SNAPSHOTTING查找,我们看依次看看 RDB 的配置:
- Reids 默认配置了三个保存策略,即：
save 900 1 # 900秒内（15分钟）,更改了1个以上的键
save 300 10 # 30秒内（5分钟）改变了10个以上的键
save 60 10000 # 60秒内改变了10000个以上的键
- 设置保存快照操作出现错误时是否停止后续数据写入硬盘，默认为 yes。
stop-writes-on-bgsave-error yes
- 指定存储至本地数据库时是否压缩数据，默认是yes，
redis采用LZF压缩，如果为了节省 CPU 时间可以关闭该选项，但会导致数据库文件变的巨大。
rdbcompression yes
- rdb 文件的校验，如果校验将避免文件格式坏掉，如果不校验将在每次操作文件时要付出校验过程的资源新能，将此参数设置为 no，将跳过校验
rdbchecksum yes
- 持久化文件名称
dbfilename dump.rdb
- 持久化文件存储路径
dir ./
实践
1）增加如下保存策略
save 1 5 # 1分钟至少更改了5个键
2）将 redis 目录下的 dump.rdb 文件删除
3）关闭 Redis 服务 ，并指定 配置文件的形式启动 Redis 服务
redis-server --service-stop
redis-server.exe redis.windows.conf
- 批量设置十个值，触发我们刚刚添加的策略
MSET a 1 a 2 a 3 a 4 a 5 a 6 a 7 a 8 a 9 a 10
5）查询 Redis 的key
127.0.0.1:6379> keys *
1) "a"
可以看到有数据
- 观察 Redis 目录，发现重新生成了
dump.rdb文件
- 将
dump.rdb文件 拷贝走，然后清除 Redis 所有数据
127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> keys *
(empty list or set)
-
关闭 redis 服务，可以看到 Redis 目录又生成了
dump.rdb文件，所以可以证明 redis 正常关闭的时候也会保存dump.rdb文件。 -
将之前拷贝的
dump.rdb文件覆盖到 Redis 目录下，然后重启 redis 服务，执行查询指令
127.0.0.1:6379> keys *
1) "a"
可以发现之前的删除的数据恢复成功了。
注：flushdb 命令会直接触发RDB快照，所以要在执行前先备份好 dump.rdb 文件。
AOF
Redis 默认是使用 RDB 持久化的，而 AOF 是处于禁用状态，我们也先来看看配置。
AOF 持久化配置
以文本形式打开 redis.conf 文件，搜索关键字 APPEND ONLY MODE查找,我们看依次看看 Redis 的配置:
- aof 默认禁用
appendonly no
- 文件名称
appendfilename "appendonly.aof"
- 保存策略
# appendfsync always
appendfsync everysec
# appendfsync no
- always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差。但数据完整性比较好（慢，安全）
- everysec：出厂默认推荐，每秒异步记录一次（默认值）
- no：不同步
- AOF 策略设置为 always 或者 everysec 时，后台处理进程(后台保存或者 AOF 日志重写)会执行大量的 I/O 操作在某些 Linux 配置中会阻止过长的 fsync() 请求。注意现在没有任何修复，即使fsync 在另外一个线程进行处理。为了减缓这个问题，可以设置下面这个参数 no-appendfsync-on-rewrite 为 no
no-appendfsync-on-rewrite no
- 重写触发机制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于64M时触发。会自动合并指令以减少日志文件体积。
- Redis 启动加载 aof 文件，如果发现末尾命令不完整则自动截掉，成功加载前面正确的数据。如果设置为no，遇到此类情况，Redis启动失败，用 redis-check-aof 工具手工修复。
aof-load-truncated yes
实践
- 启用 aof 配置
appendonly yes
- 清除之前实践的数据，将
dump.rdb和appendonly.aof文件删除，然后重启服务
redis-server --service-stop
redis-server.exe redis.windows.conf
3） 输入如下命令,观察 Redis 目录是否生成 dump.rdb 和 appendonly.aof 文件
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> MSET a 1 a 2 a 3 a 4 a 5 a 6 a 7 a 8 a 9 a 10
OK
4）将生成的 dump.rdb 和 appendonly.aof 拷贝走后，清除数据并关闭 Redis 服务
127.0.0.1:6379> flushdb
OK
- 将之前拷贝的
appendonly.aof文件覆盖 Redis 目录，重启服务
127.0.0.1:6379> keys *
1) "a"
可以看到数据也恢复了。
RDB 和 AOF 的优缺点
| 持久化方式 | 优点 | 缺点 |
|---|---|---|
| RDB | 适合大规模的数据恢复。 | 1.数据的完整性和一致性不高 2.备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。 |
| AOF | 数据的完整性和一致性更高 | 因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。 |