Redis 持久化

一、Redis 持久化方式以及工作流程：

• RDB（Redis DataBase） 持久化：能够在指定的时间间隔对你的数据进行快照存储。在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，打到数据恢复。
• AOF（Append Only File）持久化：记录每次对服务器的写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF命令以redis协议追加保存每次到写的操作到文件末尾；Redis还能对AOF文件进行后台重写(rebuild)，使得AOF文件的体积不至于过大；【自己手动开启appendonly yes配置项，默认是no】；
  

RDB工作流程【bgsave】：
1、fork一个子进程，返回父进程和子进程（下面内容有对fork详细解析）；
2、子进程将数据集写入一个临时的RDB文件里；
3、当子进程完成对新RDB文件的写入时，Redis会用新RDB文件替换原来的RDB文件，并删除旧的RDB文件；

RDB快照snapshot【在多长时间内数据集至少有多少改动】:

配置文件的配置可以到了一定的改动的话自动保存数据集；
或者也可以手动操作命令save或者bgsave,让Redis进行数据集保存操作；
例如：save 60 10000 在60秒内有10000次的改动；

save和bgsave:
save:执行这个命令时，Redis会阻塞客户端请求，同时进行快照操作；
直接在主线程操作，会阻塞其他操作请求，尽量避免使用这种方式；
bgsave：执行时，Redis还回继续接受客户端请求，异步执行快照操作；

rdbcompression:存储时是否使用压缩存储，默认为yes；使用LZF算法压缩存储；

AOF工作流程：
1、打开redis.conf：appendonly yes;
2、持久化流程操作：

• 客户端的请求写命令会被append追加到aof缓冲区；
• aof缓冲区会根据aof持久化策略【always，everysec,no】将操作sync同步到磁盘的aof文件中；
  redis < 7.0 : 当执行任何一个命令时，都会被追加到appendonly.aof 文件末尾；
  redis >=7.0 之后发生了改变：使用多部分aof机制；原始的单个aof文件被拆分成基本文件和增量文件。基本文件表示重写aof时存在的数据的初始快照，而增量文件则包含自己创建最后一个基本aof文件以来的增量修改；
• aof文件大小超过重写策略或者手动重写时，会对aof进行重写，压缩aof文件容量
• red is服务重启时，会重新加载aof文件的写操作达到数据恢复的目的

文件内容（其实就是命令）：只记录写操作，不记录读操作

3、AOF 写回磁盘策略，三种不同的方式：fsync

1. always:每次有命令直接追加到AOF文件，就执行一次fsync，慢且安全；
   2.everysec:每秒fsync一次【默认推荐】，足够快，故障丢失时也就丢失1秒钟的数据；appendfsync everysec
2. no:从不fsync,将数据丢给操作系统,由操作系统决定何时将缓冲区内容写回到硬盘；

4、aof重写机制
如果一直往aof文件里追加的话，会导致文件太大；

AOF重写触发条件：
1、手动触发bgrewriteaof 命令
2、自动触发：当AOF日志大小增长指定的百分比时自动触发；（当aof文件大小是上次rewrite后带下的2倍且文件大小大于64m的时候触发）例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写?100MB

AOF重写原理：
1、Redis接受客户端的命令后，写入到aof文件中
2、当满足重写条件后，Redis将AOF的重写程序放到子进程中执行
3、子进程在重写AOF期间，Redis主进程可以继续处理命令，当接受到新的写命令后，Reis主进程会将这个写命令的协议内容追加到现有的AOF文件，同时追加到AOF重写缓存中；
4、当子进程完成AOF重写之后，它会向父进程发送一个完成信号；
5、父进程在接到完成信后之后，会调用一个信号处理函数。将AOF重写缓存中的内容全部写入新的AOF文件中，对新的AOF文件进行改名，覆盖原有的AOF文件；

AOF文件恢复
redis-check-aof
1).备份被写坏的AOF文件
(2).运行redis-check-aof –fix filename 命令进行修复
(3).使用diff -u 命令来查看两个文件的差异，定位问题
(4).将修复完成的AOF文件移动到Redis安装目录下
(5).重启Redis ，加载修复后的AOF文件

可以同时开启两种持久化方式
当redis重启的时候会优先载入AOF文件来回复原始的数据；
在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整；

既然有两种持久化方式，那在我们选择的时候肯定要综合考虑两种方式的利弊来选择适合自己业务场景的持久化方式，所以来分析两中方式的利弊；

二、对比区分利弊

RDB优点：

• RDB是一个非常紧凑的文件，它保存了某个时间点的数据集，非常适用于数据集的备份，比如你可以在每个小时报保存过去24小时内的数据，同时每天保存过去30天的数据，这样即使出了问题你也可以根据需求恢复到不同版本的数据集。
• RDB是一个紧凑的单一文件，很方便传送一到另一个远端数据中心，非常适用于灾难恢复；
• RDB在保存RDB文件时父进程做的就是fork一个子进程，接下来的工作都有子进程进行，父进程不需要其他IO操作，所以RDB持久化可以最大化redis的性能；
• 与AOF相比，在恢复大的数据集的时候，RDB方式会快一些；

拓展：

此内容来自于百度百科：

Fork:复刻/分支；是UNIX中的分叉函数；
一个现有进程（父进程）可以调用fork函数创建一个新进程。由fork创建的新进程被称为子进程；
fork函数被调用一次返回两次，两次返回的唯一区别就是子进程中返回0值而父进程返回子进程的ID；出现错误则返回负值；
子进程是父进程的副本，它将获得父进程数据空间、堆、栈等资源的副本。父子进程间不共享这些存储空间。

RDB缺点

• RDB 是先将更新的内容放在一个临时文件，然后等到满足save的操作命令，才会将整个临时文件替换dump.rdb; 所以中间如果因为意外停止工作的话，会丢失最后更新的数据。所以如果想要数据的完整性的话，RDB不适合你；
• RDB会经常fork子进程来保存数据集到硬盘上，当数据集大的时候，fork过程非常耗时，可能会导致Redis在一些毫秒级内不能响应客户端的请求；

AOF优点

• 使用AOF会让Redis更加耐久；可以使用不同的fsync策略;appendfsync always、appendfsync everysec、appendfsync no、fsync是由后台线程进行处理的，主线程会尽力处理客户端请求，一旦出现故障，也最多就是丢失1秒的数据；
• AOF文件是一个只进行追加的日志文件，即使由于某些原因未执行完写入的命令，也可以redis-check-aof工具修复这些问题；
• Redis可以在AOF文件体积变大时，自动地在后台对AOF进行重写；执行BGREWRITEAOF命令，Redis会生成新的AOF文件，重写的新AOF文件包含了恢复当前数据集所需的最小命令集合。
  重写操作过程：继续将命令追加到原来的AOF文件，等到新的AOF文件创建完，Redis就会从旧的AOF文件切换到新AOF文件，并开始对新AOF文件进行追加操作；
• 很多时候即使你执行了FLUSHALL命令或者其他的错误命令；但只要AOF文件未被重写，那么只要停止服务器，移除appendonly.aof文件的那条命令即可；

AOF缺点

• AOF文件一直在追加，所以体积通常大于RDB文件的体积；
• 根据所使用的fsync策略，AOF速度可能会慢于RDB。

三、如何选择使用哪种持久化方式？？

1、如果可以承受一定时间内的数据丢失，可以使用RDB持久化；
2、如果想要数据完整性那就用AOF；
3、或者可以两者都选择，但是也要承受两者带来的对内存的损耗；

四、如果子进程被终止时会发生什么

当一个正在进行AOF重写的子进程被信号终止，Redis会把它当做一个错误并丢弃这个AOF文件。AOF重写过程会在以后被重新触发；
当一个正在执行RDB文件保存的子进程被终止Redis会把它当做一个严重的错误，因为AOF重写只会导致AOF文件冗余，但是RDB文件保存失败会导致Redis直接不可用；
如果一个正在保存RDB文件的子进程被信号终止或者自身出现了错误，Redis会进入一种特殊的错误状态，不允许任何写操作；
Redis会继续回复所有读操作；
Redis会回复给所有的写请求一个MISCONFIG错误；

最后最后附一张大图【来自于公众号：微观技术】