1、Redis持久化介绍

        Redis 是一款内存数据库，也就是说它把数据都存储在内存中，持久化就是把内存中的数据存储到电脑的磁盘上。

Redis 提供了不同级别的持久化方式：

1. RDB 持久化方式能够在指定的时间间隔能对你的数据进行快照存储。

2. AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据。

2、RDB介绍

2.1 RDB是什么

        RDB 是 Redis 持久化到磁盘上的数据文件的格式，重点内容默认的文件名是 dump.rdb。

        Redis 会在指定的时间间隔内将内存中的数据集快照写入磁盘，它恢复时是将快照文件直接读到内存里。

        Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

        整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

简要概况：

• RDB是一个非常紧凑的文件；
• RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做，父进程不需要再做其他lO操作，所以RDB持久化方式可以最大化redis的性能；
• 与AOF相比,在恢复大的数据集的时候，RDB方式会更快一些；
• 数据丢失风险大；
• RDB需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能会导致Redis在一些毫秒级不能相应客户端请求。

2.2 Fork的作用

        fork的作用是复制一个与当前进程一样的进程，新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

2.3 手动将redis中的数据写入磁盘

使用 save 命令，或者 bgsave 命令。

• save：该命令会阻塞其他操作，例：客户端请求。
• bgsave：该命令会在后台异步执行写操作，仍然可以处理客户端请求。
• lastsave：该命令获取最后一次成功执行快照的时间。
• flushall / flushdb：清库命令，也会刷新 dump.rdb。

2.4 从RDB文件中加载数据

        Redis 在启动的时候会自动加载 redis-server 所在的目录下的 dump.rdb 文件（如果存在的话），如果在启动 redis-server 服务的时候指定了别的配置文件，那就读取那个指定的配置文件目录下的 dump.rdb。

例如：

redis-server /myconf/redis.conf 命令执行之后就会去加载 /myconf 目录下的 dump.rdb 文件来初始化 redis。

2.5 RDB优势

        适合于大规模的数据恢复。

2.6 RDB的劣势

• 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。
• fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要慎重考虑。

2.7 redis停止写RDB文件

• 在配置文件中配置 save ""
• 在客户端执行命令：redis-cli config set save ""

3、AOF介绍

3.1 AOF是什么

        AOF 是 Append Only File 的意思，它是指 Redis 在持久化数据到硬盘的时候是以日志的形式来记录每个写操作，并保存到磁盘的一个文件中，这个文件的名字默认叫 appendonly.aof。

简单概述：

• AOF文件是一个只进行追加的日志文件；
• Redis 可以在AOF文件体积变得过大时，自动地在后台对AOF进行重写；
• 对于相同的数据集来说，AOF文件的体积通常要大于RDB文件的体积；
• 根据所使用的 fsync 策略，AOF的速度可能会慢于 RDB。

3.2 设置Redis以AOF形式的持久化

        修改 redis.conf 中的 appendonly 的值为 yes。

这样在 redis 启动的时候，就会自动执行 appendonly.aof 文件中的写操作来将数据加载到内存。

3.3 修复appendonly.aof文件

如果 appendonly.aof 文件被破坏了（文件的内容被篡改了），怎么修复？

执行：redis-check-aof --fix appendonly.aof 就可以修复，然后重启 redis 即可。

ps：这个命令会把发生错误的命令之后的部分清掉。但是，这个修复命令不是万能的，如果文件被改的太惨，修复其实就是清空整个文件（比如，在文件头部进行修改）。

3.4 配置AOF持久化策略

修改配置文件：

• appendfsync always：每个操作都会被记录到磁盘，性能差但是数据完整性比较好。
• appendfsync everysec（默认）：每秒进行一次持久化，如果一秒内宕机，那一秒内的数据就会丢失。
• appendfsync no：不进行持久化。

3.5 AOF优点

        数据的一致性高。

3.6 AOF缺点

• 相同数据量的 aof 文件相比于 rdb 文件占用的磁盘空间较大。
• redis 运行 aof 文件的速度比 rdb 文件慢。

4、RDB和AOF两种策略之间的选择

• 如果对数据的一致性要求比较高，建议使用 AOF。
• 大部分情况建议采用 RDB。
• 如果只希望数据在 Redis 服务运行的时候存在，那么可以不开启任何一种持久化策略。

如果同时启用 RDB 和 AOF 这两种策略，那么 Redis 会加载哪个文件？

        会优先加载 appendonly.aof 文件中的数据，就算只有 dump.rdb 文件，没有 appendonly.aof 文件，redis 也不会加载 dump.rdb 文件中的数据。

那要不要只使用 AOF 呢？

        建议不要，因为 RDB 更适合于备份数据库，快速重启，AOF 启动慢，执行效率也慢（因为要经常存盘）。