Redis学习总结(三)--Redis持久化

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记录的内容多，文件会越来越大，数据恢复也会越来越慢。