redis的持久化

快照： 基于硬件编程技术的一种，针对内存进行的快速读取技术。

fork： fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量，环境变量，程序计数器等)数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

redis的持久化分为：

• RDB(redis database)

1. RDB是什么：

   在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的snapshot快照，
   它恢复时是将快照文件直接读到内存里。

   redis会单独创建(fork)一个子进程进行持久化，会先将数据写入到一个临时文件中，待持久化过程结束了，再用这个临时文件替换上次持久化好的文件。
   整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那么RDB方式比AOF方式更加的高效。

   RDB默认开启，redis.conf中的具体配置参数如下；

#dbfilename：持久化数据存储在本地的文件
dbfilename dump.rdb
#dir：持久化数据存储在本地的路径，如果是在/redis/redis-3.0.6/src下启动的redis-cli，则数据会存储在当前src目录下
dir ./
##snapshot触发的时机，save <seconds> <changes>  
##如下为900秒后，至少有一个变更操作，才会snapshot  
##对于此值的设置，需要谨慎，评估系统的变更操作密集程度  
##可以通过“save “””来关闭snapshot功能  (即禁止使用rdb)

#save时间，以下分别表示更改了1个key时间隔900s进行持久化存储；更改了10个key300s进行存储；更改10000个key60s进行存储。

save 900 1
save 300 10
save 60 10000
##当snapshot时出现错误无法继续时，是否阻塞客户端“变更操作”，“错误”可能因为磁盘已满/磁盘故障/OS级别异常等
#当后台RDB进程导出快照（一部分的key-value）到rdb文件这个过程出错时（即最后一次的后台保存失败时），
#redis主进程是否还接受向数据库写数据
#该种方式会让用户知道在数据持久化到硬盘时出错了（相当于一种监控）；
#如果安装了很好的redis持久化监控，可设置为"no"

stop-writes-on-bgsave-error yes  
##是否启用rdb文件压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的网络传输时间 (如果希望RDB进程节省一点CPU时间，设置为no，但是可能最后的rdb文件会很大)

rdbcompression yes  
#在redis重启后，从rdb文件向内存写数据之前，是否先检测该rdb文件是否损坏(根据rdb文件中的校验和check_sum)
rdbchecksum yes

snapshot触发的时机，是有“间隔时间”和“变更次数”共同决定，同时符合2个条件才会触发snapshot,否则“变更次数”会被继续累加到下一个“间隔时间”上。snapshot过程中并不阻塞客户端请求。snapshot首先将数据写入临时文件，当成功结束后，将临时文件重名为dump.rdb。

详看：https://blog.csdn.net/xiaozhu0301/article/details/79021436

2. 如何触发快照：

   1）配置文件中默认的快照配置（必须进行冷拷贝后重新使用）
   2）命令save或者bgsave
   save：save时只管保存，其他不管，全部阻塞。
   bgsave：redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。
   可以通过lastsave命令获取最后一次成功执行快照的时间。
   3）执行flushall命令，也会产出dump.rdb文件，不过是空的，没什么意义。
   bgsave是异步执行的,save命令会出现卡顿, 上面在配置文件里的那些执行的时候也是bgsave
   

3. 如何恢复：
   将备份文件移动到redis安装目录并启动服务即可

4. 优势：
   适合大规模的数据恢复;
   对数据完整性和一致性要求不高

5. 劣势：
   在一定间隔时间做一次备份，所以如果redis意外down掉的话，
   就会丢失最后一次快照后的所有修改 (最后一次持久化后的数据可能丢失);
   fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑

• AOF(append only file)日志记录

6. AOF是什么:

   是以日志的形式来记录每个写操作，将redis执行过的所有写指令记录下来(读操作不记录)，只许追加文件但不可以改写文件，redis启动之初会读取该文件，重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

7. 如何恢复aof文件：

   ./redis-check-aof --fix appendonly.aof

8. 优势:

   AOF在同步数据方面给我们提供了三种同步方式，让我们可以自由选择:
   always：实时同步
   everysec ：每一秒同步
   no：无限刷新
   尽可能的保证了数据的完整性，不会丢失太多的数据，最多也就是一秒的数据。

9. 劣势：

   相同数据集的数据而言，aof文件要远大于rdb文件，恢复速度慢于rdb
   aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同。

RDB和AOF区别：

都是用来进行数据的持久化。

不过一个是以快照的形式大范围的去恢复数据，不过数据的完整性不能保证。
一个是也日志的形式去恢复数据，数据的完整性保持的好，速度慢，对大量数据的恢复做的不够好。

二者可以都存在，不过会优先去使用AOF方式进行数据恢复，如果AOF文件出错，
那么redis的服务将不能启动，造成严重的bug。
什么时候使用RDB和AOF根据具体的场景进行分析。