redis的RDB文件和AOF文件恢复数据的区别

dump.rdb文件
redis.conf配置文件
save 900 1 900秒内有 1 条记录被改动保持dump.rdb文件
save 300 10 300 秒内有 10 条记录被改动保持dump.rdb文件
save 60 10000 60 秒内有 100000 条记录被改动保持dump.rdb文件
先创建dump.rdb文件出来，我这里是主动保存

127.0.0.1:6379> set m 1
OK
127.0.0.1:6379> SAVE
OK
之后再执行
127.0.0.1:6379> set a 2
OK
127.0.0.1:6379> set b 2
OK

然后把redis的服务器kill 杀了（让redis异常退出）
然后启动redis，查看keys * ,发现没有保存的数据丢失了，因为后面的a和b没有到了保存文件的要求，导致dump.rdb文件没有更新，所以之后加入的数据丢失

127.0.0.1:6379> KEYS *
1) “m”

aof文件
redis.conf配置文件
appendonly yes 开启aof持久化
appendfsync everysec 每秒记录一次
在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF ：

redis-cli config set appendonly yes
redis-cli config set save “”

如果你愿意的话， 也可以同时使用 RDB 和 AOF 这两种持久化功能
重要：别忘了在 redis.conf 中打开 AOF 功能！否则服务器重启后，之前通过 CONFIG SET 命令设置的配置就会被遗忘， 程序会按原来的配置来启动服务器。

127.0.0.1:6379> set a 1
127.0.0.1:6379> set b 1
[root@shenzhen redis]# cat appendonly.aof
*2
$6
SELECT
$1
0
*3
$3
set
$1
a
$1
1
*3
$3
set
$1
b
$1
1
*3

然后把redis的服务器kill 杀了（让redis异常退出）
然后启动redis，查看keys * ,发现数据都在，因为使用了appendonly.aof持久化

区别
AOF 文件的体积通常要大于 RDB 文件的体积，AOF 的速度可能会慢于 RDB，AOF 文件容易读懂，AOF 文件比RDB 文件保持效率高。

分析对比两种方式并做了测试后，发现这是两种不同风格的持久化方式，那么应该如何选择呢？
对于企业级的中大型应用，如果不想牺牲数据完整性但是又希望保持高效率，那么你应该同时使用 RDB 和 AOF 两种方式；
如果你不打算耗费精力在这个地方，只需要保证数据完整性，那么优先考虑使用 AOF 方式；
RDB 方式非常适合大规模的数据恢复，如果业务对数据完整性和一致性要求不高，RDB是很好的选择。