共计 5403 个字符，预计需要花费 14 分钟才能阅读完成。
这篇文章将为大家详细讲解有关 Redis 中 RDB 和 AOF 的示例分析，丸趣 TV 小编觉得挺实用的，因此分享给大家做个参考，希望大家阅读完这篇文章后可以有所收获。
Redis 有两种持久化方案，RDB（Redis DataBase）和 AOF（Append Only File）。如果你想快速了解和使用 RDB 和 AOF，可以直接跳到文章底部看总结。本章节通过配置文件，触发快照的方式，恢复数据的操作，命令操作演示，优缺点来学习 Redis 的重点知识持久化。
RDB 详解
RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行指定次数的写操作，则会将内存中的数据写入到磁盘中。即在指定目录下生成一个 dump.rdb 文件。Redis 重启会通过加载 dump.rdb 文件恢复数据。
从配置文件了解 RDB
打开 redis.conf 文件，找到 SNAPSHOTTING 对应内容
1 RDB 核心规则配置（重点）
save seconds changes
# save
save 900 1
save 300 10
save 60 10000解说：save 指定时间间隔 执行指定次数更新操作，满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900 秒内有 1 个更改，300 秒内有 10 个更改以及 60 秒内有 10000 个更改，则将内存中的数据快照写入磁盘。
若不想用 RDB 方案，可以把 save 的注释打开，下面三个注释。
2 指定本地数据库文件名，一般采用默认的 dump.rdb
dbfilename dump.rdb3 指定本地数据库存放目录，一般也用默认配置
dir ./
4 默认开启数据压缩
rdbcompression yes解说：配置存储至本地数据库时是否压缩数据，默认为 yes。Redis 采用 LZF 压缩方式，但占用了一点 CPU 的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。
触发 RDB 快照
1 在指定的时间间隔内，执行指定次数的写操作
2 执行 save（阻塞，只管保存快照，其他的等待）或者是 bgsave（异步）命令
3 执行 flushall 命令，清空数据库所有数据，意义不大。
4 执行 shutdown 命令，保证服务器正常关闭且不丢失任何数据，意义 … 也不大。
通过 RDB 文件恢复数据
将 dump.rdb 文件拷贝到 redis 的安装目录的 bin 目录下，重启 redis 服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份 dump.rdb。可以从下面的操作演示中可以体会到。
RDB 的优缺点
优点：
1 适合大规模的数据恢复。
2 如果业务对数据完整性和一致性要求不高，RDB 是很好的选择。
缺点：
1 数据的完整性和一致性不高，因为 RDB 可能在最后一次备份时宕机了。
2 备份时占用内存，因为 Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。
所以 Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。
操作演示
[root@itdragon bin]# vim redis.conf
save 900 1
save 120 5
save 60 10000
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379 keys *
(empty list or set)
127.0.0.1:6379 set key1 value1
127.0.0.1:6379 set key2 value2
127.0.0.1:6379 set key3 value3
127.0.0.1:6379 set key4 value4
127.0.0.1:6379 set key5 value5
127.0.0.1:6379 set key6 value6
127.0.0.1:6379 SHUTDOWN
not connected QUIT
[root@itdragon bin]# cp dump.rdb dump_bk.rdb
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379 FLUSHALL
127.0.0.1:6379 keys *
(empty list or set)
127.0.0.1:6379 SHUTDOWN
not connected QUIT
[root@itdragon bin]# cp dump_bk.rdb dump.rdb
cp: overwrite `dump.rdb ? y
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379 keys *
1) key5
2) key1
3) key3
4) key4
5) key6
6) key2第一步：vim 修改持久化配置时间，120 秒内修改 5 次则持久化一次。
第二步：重启服务使配置生效。
第三步：分别 set 5 个 key，过两分钟后，在 bin 的当前目录下会自动生产一个 dump.rdb 文件。（set key6 是为了验证 shutdown 有触发 RDB 快照的作用）
第四步：将当前的 dump.rdb 备份一份（模拟线上工作）。
第五步：执行 FLUSHALL 命令清空数据库数据（模拟数据丢失）。
第六步：重启 Redis 服务，恢复数据 ….. 咦？？？？(′◔ ‸◔`)。数据是空的？？？？这是因为 FLUSHALL 也有触发 RDB 快照的功能。
第七步：将备份的 dump_bk.rdb 替换 dump.rdb 然后重新 Redis。
注意点：SHUTDOWN 和 FLUSHALL 命令都会触发 RDB 快照，这是一个坑，请大家注意。
其他命令：
keys * 匹配数据库中所有 key save 阻塞触发 RDB 快照，使其备份数据 FLUSHALL 清空整个 Redis 服务器的数据 (几乎不用) SHUTDOWN 关机走人（很少用）
AOF 详解
AOF：Redis 默认不开启。它的出现是为了弥补 RDB 的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
从配置文件了解 AOF
打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容
1 redis 默认关闭，开启需要手动把 no 改为 yes
appendonly yes2 指定本地数据库文件名，默认值为 appendonly.aof
appendfilename appendonly.aof3 指定更新日志条件
# appendfsync always
appendfsync everysec
# appendfsync no解说：
always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不同步
4 配置重写触发机制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb解说：当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发。一般都设置为 3G，64M 太小了。
触发 AOF 快照
根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。
根据 AOF 文件恢复数据
正常情况下，将 appendonly.aof 文件拷贝到 redis 的安装目录的 bin 目录下，重启 redis 服务即可。但在实际开发中，可能因为某些原因导致 appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令 redis-check-aof –fix appendonly.aof 进行修复。从下面的操作演示中体会。
AOF 的重写机制
前面也说到了，AOF 的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当 AOF 文件的大小超过所设定的阈值时，Redis 就会对 AOF 文件的内容压缩。
重写的原理：Redis 会 fork 出一条新进程，读取内存中的数据，并重新写到一个临时文件中。并没有读取旧文件（你都那么大了，我还去读你？？？o(ﾟДﾟ) っ傻啊！）。最后替换旧的 aof 文件。
触发机制：当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发。这里的“一倍”和“64M”可以通过配置文件修改。
AOF 的优缺点
优点：数据的完整性和一致性更高
缺点：因为 AOF 记录的内容多，文件会越来越大，数据恢复也会越来越慢。
操作演示
[root@itdragon bin]# vim appendonly.aof
appendonly yes
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379 keys *
(empty list or set)
127.0.0.1:6379 set keyAOf valueAof
127.0.0.1:6379 FLUSHALL
127.0.0.1:6379 SHUTDOWN
not connected QUIT
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379 keys *
1) keyAOf
127.0.0.1:6379 SHUTDOWN
not connected QUIT
[root@itdragon bin]# vim appendonly.aof
fjewofjwojfoewifjowejfwf
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused
not connected QUIT
[root@itdragon bin]# redis-check-aof --fix appendonly.aof
x 3e: Expected prefix * , got:
AOF analyzed: size=92, ok_up_to=62, diff=30
This will shrink the AOF from 92 bytes, with 30 bytes, to 62 bytes
Continue? [y/N]: y
Successfully truncated AOF
[root@itdragon bin]# ./redis-server redis.conf
[root@itdragon bin]# ./redis-cli -h 127.0.0.1 -p 6379
127.0.0.1:6379 keys *
1) keyAOf
第一步：修改配置文件，开启 AOF 持久化配置。
第二步：重启 Redis 服务，并进入 Redis 自带的客户端中。
第三步：保存值，然后模拟数据丢失，关闭 Redis 服务。
第四步：重启服务，发现数据恢复了。（额外提一点：有教程显示 FLUSHALL 命令会被写入 AOF 文件中，导致数据恢复失败。我安装的是 redis-4.0.2 没有遇到这个问题）。
第五步：修改 appendonly.aof，模拟文件异常情况。
第六步：重启 Redis 服务失败。这同时也说明了，RDB 和 AOF 可以同时存在，且优先加载 AOF 文件。
第七步：校验 appendonly.aof 文件。重启 Redis 服务后正常。
补充点：aof 的校验是通过 redis-check-aof 文件，那么 rdb 的校验是不是可以通过 redis-check-rdb 文件呢？？？
总结 Redis 默认开启 RDB 持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。Redis 需要手动开启 AOF 持久化方式，默认是每秒将写操作日志追加到 AOF 文件中。
AOF 的数据完整性比 RDB 高，但记录内容多了，会影响数据恢复的效率。Redis 针对 AOF 文件大的问题，提供重写的瘦身机制。若只打算用 Redis 做缓存，可以关闭持久化。若打算使用 Redis 的持久化。建议 RDB 和 AOF 都开启。其实 RDB 更适合做数据的备份，留一后手。AOF 出问题了，还有 RDB。
关于“Redis 中 RDB 和 AOF 的示例分析”这篇文章就分享到这里了，希望以上内容可以对大家有一定的帮助，使各位可以学到更多知识，如果觉得文章不错，请把它分享出去让更多的人看到。
