[TOC]

1 Redis持久化

持久化，顾名思义就是将数据存储到存储介质中。Redis 提供了不同级别的持久化方式:

• RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储.
• AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大.
• 如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
• 可以同时开启两种持久化方式。 此时,redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集比RDB文件保存的数据集要完整.

2 RDB

2.1 优点

• RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集.
• RDB是一个紧凑的单一文件,很方便传送到另一个远端数据中心.
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他IO操作，所以RDB持久化方式可以最大化redis的性能.
• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些.

2.2 缺点

• 如果你希望在redis意外停止工作（例如电源中断）的情况下丢失的数据最少的话，那么RDB不适合你.虽然你可以配置不同的save时间点(例如每隔5分钟并且对数据集有100个写的操作),是Redis要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在Redis意外宕机,你可能会丢失几分钟的数据.
• RDB 需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级内不能响应客户端的请求.如果数据集巨大并且CPU性能不是很好的情况下,这种情况会持续1秒,AOF也需要fork,但是你可以调节重写日志文件的频率来提高数据集的耐久度.

2.3 RDB中的fock

此处的fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）

数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

2.4 RDB的触发条件

• 根据配置文件中的配置，比如:

save 900 1 #   after 900 sec --(15 min) 15分钟内至少有一个key改变
save 300 10 #   after 300 sec --(5 min) 5分钟内至少10个key改变
save 60 10000 #   after 60 sec --60秒内至少10000个key改变

• save命令触发

save时只管保存，其它不管，客户端请求全部阻塞

• bgsave

在后台异步进行快照操作，快照同时还可以响应客户端请求。

可以通过lastsave命令获取最后一次成功执行快照的时间。

• 当执行flushall的时候,其实也触发了save操作,但是会将rdb文件情况,没实际意义.

2.5 从RDB文件恢复数据

将.rdb数据库文件复制到redis配置文件中SNAPSHOTTING段指定的dir指令配置的目录,启动redis即可。

默认就是你启动redis时所在的目录。

################################ SNAPSHOTTING  ################################
# 省略其他配置
# 请注意:必须指定一个目录,而不是一个文件名.
dir ./

该选项的值可以通过以下命令动态获取:

127.0.0.1:6379> CONFIG GET dir
1) "dir"
2) "/soft"
127.0.0.1:6379>  

2.6 禁用RDB

• 动态通过命令禁用

redis-cli config set save ""

• 配置文件中禁用

################################ SNAPSHOTTING  ################################
# 省略其他配置
#   save ""

2.7 RDB的适用场景

• 大规模的数据恢复(此时往往比AOF快)
• 对数据完整性和一致性要求不高的场景(最后的数据可能会丢失)

3 AOF

3.1 优点

• 使用AOF 会让你的Redis更加耐久: 你可以使用不同的fsync策略：
  • 无fsync
  • 每秒fsync
  • 每次写的时候fsync
  • 使用默认的每秒fsync策略,Redis的性能依然很好(fsync是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障，你最多丢失1秒的数据.
• AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题.
• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
• AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

3.2 缺点

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积.
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）

3.3 AOF重写

什么是AOF重写？

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制：

当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集.

就大概是下面这个意思:

127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> set k1 v2
OK
127.0.0.1:6379> set k1 v3
OK

其实以上命令最终就是和下面命令等价的：

127.0.0.1:6379> set k1 v3

原理

Reids会fork出一条新进程来将文件重写(先写临时文件最后再rename)，遍历新进程的内存数据，每条记录有一条set语句。

重写aof文件的操作,不读取旧的aof文件,而是将整个内存中的数据内容用命令的方式重写了一个新的aof文件.

3.4 AOF重写的触发条件

• 手动触发

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

• AOF大小超出auto-aof-rewrite-min-size并且AOF增长率到达auto-aof-rewrite-percentage

############################## APPEND ONLY MODE ###############################
# 省略其他配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

3.5 从AOF恢复数据

• 启用AOF

############################## APPEND ONLY MODE ###############################
# 省略其他配置
appendonly yes

• 修复AOF文件(如果文件已经损坏的话)

redis-check-aof --fix appendonly.aof

• 将aof文件复制到redis配置文件中SNAPSHOTTING段指定的dir指令配置的目录,启动redis即可。

3.6 RDB到AOF的动态切换

在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF ：

• 备份dump.rdb
• 动态启用AOF

redis-cli config set appendonly yes

• 动态关闭RDB

redis-cli config set save “”

• 修改配置文件以保证永久生效

4 选哪个呢？

• AOF和RDB同时启用

  • 最好是将RDB和AOF同时开启。
  • 在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据
  • 因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整

• 只使用RDB

  • 如果可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

• 只使用AOF

  • 作者并不建议这样做

  • 因为RDB更适合用于备份数据库(AOF在不断变化不好备份),

    快速重启，而且不会有AOF可能潜在的bug，留着作为一个以防万一的手段。

• 两个都不用

  • 如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。
  • 这时候也就是相当于一个真正意义上的缓存了。

参考资料

• 尚硅谷思维导图
• https://redis.io/documentation
• http://www.redis.cn/documentation.html