redis持久化：RDB和AOF

[diaosichengxuyuan]

一. Redis 持久化:

(1)redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。
(2)RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；
(3)AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。
(4)其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高，但是默认情况下，AOF是关闭的，RDB是打开的。
(5)如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。

二. RDB

1.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.rdb

(3)指定本地数据库存放目录，一般也用默认配置

dir ./

(4)默认开启数据压缩

rdbcompression yes

配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。

2.RDB优点

RDB非常适合用于进行备份和灾难恢复，它是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集：比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。

3.RDB缺点

(1)服务器故障时可能丢失数据。虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。
(2)每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。

4.RDB快照

当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：
(1)redis调用系统的fork()函数创建一个子进程
(2)子进程将数据集写入一个临时的RDB文件
(3)当子进程完成对临时的RDB文件的写入时，redis用新的RDB文件来替换原来旧的RDB文件，并将旧的RDB文件删除

三.AOF

1.AOF配置

打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容
(1)redis 默认关闭，开启需要手动把no改为yes

appendonly yes

(2)指定本地数据库文件名，默认值为 appendonly.aof

appendfilename "appendonly.aof"

(3)指定更新日志条件

# 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太小了。

2.AOF优点

(1)AOF可以更好的保护数据不丢失，一般AOF会以每隔1秒，通过后台的一个线程去执行一次fsync操作，如果redis进程挂掉，最多丢失1秒的数据。
(2)Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写
(3)AOF日志文件的命令通过非常可读的方式进行记录，这个非常适合做灾难性的误删除紧急恢复，如果某人不小心用flushall命令清空了所有数据，只要这个时候还没有执行rewrite，那么就可以将日志文件中的flushall删除，进行恢复。

3.AOF缺点

(1)对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
(2)数据恢复比较慢，不适合做冷备。

4.AOF重写

(1)在重写即将开始之际，redis会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。
(2)与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。
(3)当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。
(4)当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了。

5.AOF文件修复

(1)使用 Redis 附带的 redis-check-aof 程序，对原来的 AOF 文件进行修复。

$ redis-check-aof --fix

(2)使用 diff -u 对比修复后的 AOF 文件和原始 AOF 文件的备份，查看两个文件之间的不同之处。
(3)重启 Redis 服务器，等待服务器载入修复后的 AOF 文件，并进行数据恢复。