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 启动慢，执行效率也慢（因为要经常存盘）。
