redis持久化RDB与AOF

RDB简介

RDB是Redis默认用来进行持久化的一种方式，根据配置文件中的save m n配置自动触发bgsave将当前内存中的数据集以快照的方式写入到磁盘中并生成一个.rdb文件，文件默认叫做dump.rdb。恢复数据时也是通过解析dump.rdb中的数据到内存中。

持久化触发条件

RDB持久化的触发分为手动触发和自动触发两种。
1）手动触发
save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求。（基本已废弃，效率太慢）
（ps:拿网络中的一副图给大家举例展示）

bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程(即Redis主进程)则继续处理请求。（rdb最主要的持久化方式）

bgsave持久化，redis会单独创建（fork）一个子进程来进行持久化操作，将数据写入到一个临时文件中，等持久化过程正常结束后，再用这个临时文件替换上次持久化好的.rdb文件。
整个过程，主进程不会进行任何IO操作，且只有fork的子线程时会阻塞服务器，同时也可以处理其他客户端发来的请求，这就确保了极高的性能。
（ps:拿网络中的一副图给大家举例展示）

另外在执行shutdown丶flushdball等敏感命令时也会触发bgsave，目的是防止还没触发自动持久化的阀值时，造成数据丢失的问题。

2）自动触发
自动触发最常见的情况是在配置文件中通过save m n的规则，指定当m秒内至少发生n次变化时，达到了自动触发的阀值，会触发bgsave。

其中save 900 1的含义是：900秒内redis数据发生了至少1次变化，则执行bgsave；save 300 10和save 60 10000同理。当三个save条件满足任意一个时，都会引起bgsave的调用。

RDB的优缺点

优点
1.效率高，每次持久化都是通过frok一个子线程来进行，且主线程不用进行IO操作。
2.数据恢复快，适合大规模恢复数据。
3.恢复数据比较简单，只用将dump.rdb放到redis的安装目录下即可。redis启动时自动解析指定目录下的dump.rdb文件，然后渲染到内存中。可在redis命令行通过CONFIG GET dir 命令获取安装目录
缺点：
1.持久化不是实时的，是根据自动持久化的阀值触发持久化，也就是说还没有打到阀值，触发自动持久化时服务器断电，就会导致最后一次还未进行持久化的数据丢失。
2.bgsave时占用内存，因为Redis 在持久化时会独立创建一个子进程，将当前时间节点下的数据写入到一个临时文件，如果不采用压缩算法（此时内存中的数据就是原来的两倍），最后才会将临时文件替换之前的备份文件，内存中临时的数据才会消失。（因此不要频繁进行持久化操作）

AOF简介

aof是redis持久化技术之一，它就是改写操作日志，通过记录每次对redis改写的操作，并追加到appendonly.aof文件中（ps:实际上就是一个历史操作记录文件，但不记录读操作），然后每次启动redis恢复数据时，就是将appendonly文件中的改写命令全部重新执行一遍。

AOF的三种持久化规则

aof默认不开启，如果要开启则将redis.conf中的appendonly 改为yes，然后重启redis即可。

appendfsync always #每次修改都会进行同步保存，消耗性能 appendfsync everysec #每秒执行一次同步保存，但可能丢失一秒的数据 appendfsync on #永不同步

AOF的重写机制

AOF的工作原理是将写操作追加到文件中，文件的冗余内容会越来越多。所以Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时，Redis就会对AOF文件的内容压缩。

触发机制：当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

重写的原理：Redis 会fork出一条新进程，读取内存中的数据，保证结果不变的前提下以更少的redis命令重新写到一个临时文件中，并不会读取旧文件也没有去改变旧文件（因为太大了）最后替换旧的aof文件。
举例：
如果服务器对键 list 执行了以下四条命令：

RPUSH list 1 2 3 4 // [1, 2, 3, 4] RPOP list // [1, 2, 3] LPOP list // [2, 3] LPUSH list 1 // [1, 2, 3]

那么当前列表键 list 在数据库中的值就为 [1, 2, 3] 。
在没有重写之前我们的aof文件中就会将上面4条命令都记录下来，而触发重写时则会读取当前内存中list的值，然后用RPUSH list 1 2 3来代替前面的4条命令。通过直接读取redis中的值，优化语句便可以压缩aof文件的大小并提高恢复数据的效率。

AOF文件修复

如果aof有错误，那么在启动redis时，启动则失败。

此时我们可以通过redis自带的redis-check-aof --fix指定文件进行修复。

redis-check-aof --fix appendonly.aof

AOF的优缺点

优点：
1.数据完整性高，如果公司内对缓存数据有非常高的数据完整性要求，则可使用aof。
缺点：
1.数据恢复慢，因为是重新执行一遍改写操作。
2.因为是实时性，所以效率比rdb慢。