redis中的持久化

什么是Redis持久化？

所谓的持久化就是让数据一直有所保留，而不是因为外部的计算机断电等行为，造成数据的丢失。而计算机中的内存条是RAM随机存储器，内存这种东西可以随意存取，与存取的速度和地方都无关，但是一旦断电关机就会丢失数据。而磁盘是固定的，不会因为断电等行为使数据丢失。redis是内存数据库为了保持数据的持久化，肯定是要将数据从内存中读取再保存到磁盘上的，而这个过程就是redis的持久化。

持久化方式

一种是快照持久化，采用隔段时间创建内存里面的数据副本。第二种AOF持久化，将导致数据变化的写命令写到AOF文件尾部。

快照方式的配置

save 900 1
save 300 10
save 60 10000

① 如果1个键key改变，那么隔900秒（15分钟）的时间就会将改变的值存储到硬盘。
② 如果10个键key改变，那么隔300秒（5分钟）的时间就会将改变的值存储到硬盘。
③ 如果10000个键key改变，那么隔10000秒的时间就会将改变的值存储到硬盘。

rdbcompression yes

启动rdb文件压缩，耗费CPU资源，默认为yes

rdbchecksum yes

对RDB数据进行数据校验

dbfilename dump.rdb

rdb文件名称

dir ./

rdb文件的位置

快照的过程

① Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）。
② 父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入到磁盘中的临时文件。
③ 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件。

手动发起快照操作

在redis中，我们也可以手动的发起快照保存，来保存我们的数据，常用的命令如下：
save ： 手动进行快照操作。
bgsave：手动的采用异步方式进行快照操作。
lastsave : 获取最后一次成功执行快照的时间。
shutdown : 同步保存到服务器并关闭redis服务器。
bgrewriteaof : 当日志文件过长时优化AOF日志文件存储。
注意：save命令和bgsave命令的区别：
save命令是由主进程进行快照，会阻塞其他的请求。bgsave命令是由fork函数复制一份的子进程进行快照的。

快照的优缺点

① 优点：适合大规模的数据恢复。对数据的完整性和一致性要求不高。
② 缺点：由于rdb的方式是每隔一段时间进行一次数据备份的，如果redis突然down掉，那么丢失的最后一次快照后的修改就业丢失了。

使用dump文件恢复redis数据

查看dump文件位置：

127.0.0.1:6380> CONFIG GET dir
1) "dir"
2) "/sunpy/redis/redis-3.2.2/src"

或者直接看redis.conf中的配置dir。将需要恢复的文件放在"/sunpy/redis/redis-3.2.2/src"目录下即可。

AOF方式的配置

appendonly yes

开启AOF持久化

appendfilename "appendonly.aof"

AOF文件名称

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

当前AOF的文件大小超过了上一次重写时的AOF文件大小的百分之多少时会再次进行重写。如果之前没有重写过，那么则以启动时的AOF文件大小为依据。
限制了允许重写的最小AOF文件大小，通常在AOF文件很小的时候即使其中有些冗余的命令也是可以忽略的。

# appendfsync always
appendfsync everysec
# appendfsync no

appendfsync always : 同步持久化，每次发生数据变更就被立即记录到磁盘。性能比较差，但是数据完整性比较好。
appendfsync everysec : 出厂默认推荐，异步操作，每秒往磁盘写入一次，如果一秒内出现宕机，数据就会丢失。在性能和持久化方面最了很好的折中
appendfsync no : 完全依赖操作系统，性能好的时候就持久，不好的时候就不持久化。