Redis数据库持久化机制------RDB和AOF详解

一.持久化

持久化是将程序数据在持久状态和瞬时状态间转换的机制。通俗的讲，就是瞬时数据（比如内存中的数据，是不能永久保存的）持久化为持久数据，持久化数据存放的两个位置：

• 内存：高效、断电（关机）内存数据会丢失
• 硬盘：读写速度慢于内存，断电数据不会丢失

二.RDB

• RDB是redis的默认持久化机制。RDB相当于照快照，保存的是一种状态。

• 快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。

RDB原理

当满足条件时,redis需要执行RDB的时候服务器会执行以下操作：

1. redis调用系统的fork()函数创建一个子进程
2. 子进程将数据集写入一个临时的RDB文件
3. 当子进程完成对临时的RDB文件的写入时，redis用新的RDB文件来替换原来旧的RDB文件，并将旧的RDB文件删除

redis在进行快照的过程中不会对RDB文件进行修改，只有快照结束后才会将旧快照替换成新快照，也就是说任何时候RDB都是完整的

快照条件

• 服务器正常关闭时，./bin/redis-cli shutdown
• key满足一定条件时，会进行快照，可以在redis.conf中查看：

# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1 //每900秒（15分钟）至少1个key发生变化，产生快照
save 300 10 //每300秒（5分钟）至少10个key发生变化，产生快照
save 60 10000 //每60秒（1分钟）至少10000个key发生变化，产生快照

优点 & 缺点

优点：

• Redis加载RDB恢复数据远远快于AOF方式
• RDB对redis对外提供读写服务的时候，影像非常小，因为redis 主进程只需要fork一个子进程出来
• RDB是一个紧凑压缩的二进制文件，代表Redis在某一个时间点上的数据快照。非常适合用于备份，全量复制等场景

缺点：

• RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，即不支持实时持久化
• 存在老版本Redis服务无法兼容新版RDB格式的问题

三.AOF

Append-only file:aof 比快照方式有更好的持久化性，是由于在使用aof 持久化方式时,redis 会将每一个收到的写命令都通过write 函数追加到文件中(默认是appendonly.aof)。当redis 重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。

AOF三种方式：

•	appendonly yes //启用 aof 持久化方式
•	appendfsync always //收到写命令就立即写入磁盘，最慢，但是保证完全的持久化
•	appendfsync everysec //每秒钟写入磁盘一次，在性能和持久化方面做了很好的折中
•	appendfsync no //完全依赖 os，性能最好,持久化没保证

优点 & 缺点

优点：

• AOF可以更好的保护数据不丢失，一般AOF会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失1秒的数据,实时性强于RDB
• AOF以appen-only的模式写入，所以没有任何磁盘寻址的开销，写入性能非常高
• 注：fsync函数：把文件在内存中的部分写回磁盘

缺点：

• 对于同一份文件AOF文件比RDB数据快照要大。例如我们调用 incr test命令 100 次，文件中必须保存全部的 100 条命令，其实有 99 条都是多余的
• AOF开启后支持写的QPS会比RDB支持的写的QPS低，因为AOF一般会配置成每秒fsync操作，每秒的fsync操作还是很高的 注:QPS每秒查询率
• 数据恢复比较慢，不适合做冷备 冷备：冷备是指两个服务器，一台运行，一台不运行做为备份。这样一旦运行的服务器宕机，就把备份的服务器运行起来

总结 如何选择持久化方式：

综合AOF和RDB两种持久化方式，用AOF来保证数据不丢失，作为恢复数据的第一选择；用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，可以使用RDB进行快速的数据恢复