持久化
一般而言，redis在运行时是将数据存在内存里的，但为了数据安全持久化方法。即 按一定方式 将内存的数据 存储到磁盘文件里，用做备份。万一 redis 因故停止，可用来恢复数据。
redis提供了两种策略机制，也就是RDB和AOF
RDB
RDB其实就是把数据以快照的形式保存在磁盘上，指在指定的时间间隔内将内存中的数据集快照写入磁盘。
RDB是默认的持久化方式，这种方式是就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。
RDB快照是一次全量备份，每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。
相关配置：
| 配置项 | 说明 |
|---|---|
| dbfilename dump.rdb | 指定本地数据库文件名，默认值为 dump.rdb |
| dir ./ | 指定持久化文件存放目录， “./” 是指 启动server的那个目录，即 在哪个目录下运行 redis-server命令，dump.rdb 就在哪个目录下生成，恢复数据也在该目录下找 dump.rdb |
| rdbcompression yes | 指定存储至本地数据库时是否压缩数据，默认为 yes，Redis 采用 LZF 压缩，如果为了节省 CPU 时间，可以关闭该选项，但会导致数据库文件变的巨大 |
| save <seconds> <changes> | 指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合 Redis 默认配置文件中提供了三个条件：save 900 1 900 秒（15 分钟）内有 1 个更改, save 300 10 300 秒（5 分钟）内有 10 个更改, save 60 10000 60 秒内有 10000 个更改。 |
| stop-writes-on-bgsave-error | 指当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据，默认值为yes |
| rdbchecksum | 默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验 |
持久化触发条件
- 满足 配置文件中 save 配置
- 执行 save 命令 ，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止
- 执行 bgsave 命令 ， 在后台异步进行快照操作，快照同时还可以响应客户端请求
- 执行 FLUSHDB 命令
- 执行 flushall 命令
- 执行 shutdown 命令
- kill redis 进程
对于RDB来说，提供了三种机制：save、bgsave、自动化。
RDB 的优势和劣势
1）优点：
- RDB文件紧凑，全量备份，非常适合用于进行备份和灾难恢复
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
2）缺点：
- Redis 都要 fork() 出一个子进程, 并复制一份数据，如果数据量很大的话，持久化会非常耗时，耗cpu资源。
- 持久化是间隔一定时间（根据save 配置而定）才做一次，可能是好几分钟， 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据
AOF
AOF 的工作方式就是： 每当有一个写命令过来时，就直接追加保存在AOF文件中。即记录每个写命令（读命令并不关心）。默认 文件名 appendonly.aof。
相关配置：
| 配置项 | 说明 |
|---|---|
| appendonly no | 指定是否在每次更新操作后进行日志记录，默认为 no |
| appendfilename appendonly.aof | 指定更新日志文件名，默认为 appendonly.aof |
| appendfsync everysec | 指定更新日志策略，共有 3 个可选值：no：表示不执行fsync，等操作系统进行数据缓存同步到磁盘（快），always：表示每次更新操作后手动调用 fsync() 将数据写到磁盘（慢，安全），everysec：表示每秒同步一次（折中，默认值） |
| no-appendfsync-on-rewrite no | 在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间。设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no |
| auto-aof-rewrite-percentage 100 | aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写 |
| auto-aof-rewrite-min-size：64mb | 允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写 |
| aof-load-truncated yes | 是否载入截断了的aof，默认yes。 redis宕机或者异常终止不会造成aof尾部不完整，如果选择的是yes，redis重启时，截断的aof文件会被导入，且redis启动成功。如果是no，用户必须手动redis-check-aof修复AOF文件后，才可以启动redis |
| dir ./ | 指定持久化文件存放目录， “./” 是指 启动server的那个目录，即 在哪个目录下运行 redis-server命令， appendonly.aof 就在哪个目录下生成，恢复数据也在该目录下找 appendonly.aof |
aof 和 rdb 生成的文件都在相同的目录 都由 “dir” 指定。
aof 重写
因为 AOF 的运作方式是不断地将命令追加到文件的末尾， 所以随着写入命令的不断增加， AOF 文件的体积也会变得越来越大。
举个例子， 如果你对一个计数器调用了 100 次 INCR key ， 那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录（entry）。
然而在实际上， 只使用一条 SET key value [EX seconds] [PX milliseconds] [NX|XX] 命令已经足以保存计数器的当前值了， 其余 99 条记录实际上都是多余的。
为了处理这种情况， Redis 支持一种有趣的特性： 可以在不打断服务客户端的情况下， 对 AOF 文件进行重建（rebuild），生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。
AOF 的优势和劣势
1）优点：
- 你可以设置不同的 fsync 策略，AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。
- AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 磁盘寻址 ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题
- AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。
- AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据
2）缺点：
- 对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
- 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）
- AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。
RDB 和 AOF ，该用哪一个？
首先这两种方法 可以同时 使用，同时使用数据会更安全
如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。
如果redis 只作为缓存 使用的话 可以 都不用。
同时使用时：重启redis 时 ，会先 导入 appendonly.aof ，再导入 dump.rdb