Redis持久化存储策略机制（RDB、AOF）

1、Redis持久化介绍

1.1 持久化机制概述

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

        由于Redis的数据都存放在内存中，如果没有配置持久化，Redis重启后数据就全丢失了，于是需要开启Redis的持久化功能，将数据保存到磁盘上，当Redis重启后，可以从磁盘中恢复数据。

        对于Redis而言，持久化机制是指把内存中的数据存为硬盘文件， 这样当Redis重启或服务器故障时能根据持久化后的硬盘文件恢复数据。

1.2 持久化机制意义

        redis持久化的意义，在于故障恢复。比如部署了一个redis，作为cache缓存，同时也可以保存一些比较重要的数据。

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

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

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

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 配置dump.rdb文件

RDB保存的文件，在redis.conf中配置文件名称，默认为dump.rdb。

rdb文件的保存位置，也可以修改。默认在Redis启动时命令行所在的目录下。

rdb文件的保存路径，也可以修改。默认为Redis启动时命令行所在的目录下

2.4 触发机制(三种)

快照默认配置：

• save 3600 1：表示3600秒内（一小时）如果至少有1个key的值变化，则保存。
• save 300 100：表示300秒内（五分钟）如果至少有100个 key 的值变化，则保存。
• save 60 10000：表示60秒内如果至少有 10000个key的值变化，则保存。

2.5 配置新的保存规则

        给redis.conf添加新的快照策略，30秒内如果有5次key的变化，则触发快照。配置修改后，需要重启Redis服务。

save 3600 1
save 300 100
save 60 10000
save 30 5

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

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

• save：该命令会阻塞其他操作，例：客户端请求。执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止，不建议使用。
• bgsave：该命令会在后台异步执行写操作，仍然可以处理客户端请求。
• lastsave：该命令获取最后一次成功执行快照的时间。
• flushall / flushdb：清库命令，也会刷新 dump.rdb。

2.7 从RDB文件中加载数据（恢复数据）

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

        只需要将rdb文件放在Redis的启动目录，Redis启动时会自动加载dump.rdb并恢复数据。

例如：

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

2.8 redis停止写RDB文件

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

2.9 高级配置

stop-writes-on-bgsave-error： 默认值是yes。当Redis无法写入磁盘的话，直接关闭Redis的写操作。

rdbcompression：默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。

rdbchecksum：默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。

2.10 RDB优势

• 适合大规模的数据恢复
• 对数据完整性和一致性要求不高更适合使用
• 节省磁盘空间
• 恢复速度快

2.11 RDB的劣势

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

3、AOF持久化机制介绍

3.1 AOF是什么

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

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来。

简单概述：

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

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

        AOF默认不开启，修改 redis.conf 中的 appendonly 的值为 yes。可以在redis.conf中配置文件名称，默认为appendonly.aof。

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

注意：

• AOF文件的保存路径，同RDB的路径一致，如果AOF和RDB同时启动，Redis默认读取AOF的数据。
•  修改完需要重启redis服务。

3.3 修复appendonly.aof文件

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

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

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

3.4 配置AOF持久化策略

修改配置文件：

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

3.5 AOF优点

• 数据的一致性高。
• 备份机制更稳健，丢失数据概率更低。
• 可读的日志文本，通过操作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 启动慢，执行效率也慢（因为要经常存盘）。

不要仅仅使用RDB：RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据。

也不要仅仅使用AOF：1通过AOF做冷备，没有RDB做冷备，来的恢复速度更快；RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug。

综合使用AOF和RDB两种持久化机制：用AOF来保证数据不丢失，作为数据恢复的第一选择，用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。