redis之持久化

1.什么是redis的持久化

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

2.redis持久化之RDB

RDB方式又叫做snap shotting（快照）方式持久化。此种方式是redis默认开启的。

上图中第一个箭头就是配置的介绍：

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

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

如果10000个键key改变，那么隔10000秒的时间就会将改变的值存储到硬盘。

优点：

适合大规模的数据恢复。对数据的完整性和一致性要求不高。

缺点：

由于rdb的方式是每隔一段时间进行一次数据备份的，如果redis突然down掉，那么丢失的最后一次快照后的修改就业丢失了。

手动发起快照持久化：

在redis中，我们也可以手动的发起快照保存，来保存我们的数据，常用的命令如下：

save ： 手动进行快照操作。

bgsave：手动的采用异步方式进行快照操作。

lastsave : 获取最后一次成功执行快照的时间。

shutdown : 同步保存到服务器并关闭redis服务器。

bgrewriteaof : 当日志文件过长时优化AOF日志文件存储。

save命令和bgsave命令的区别：

save命令是由主进程进行快照，会阻塞其他的请求。bgsave命令是由fork函数复制一份的子进程进行快照的。

redis中的RDB文件：

默认的RDB的文件路径是在当前目录，文件名是dump.rdb，可以在配置文件中修改路径和文件名，分别是dir和dbfilename。

RDB持久化方式的数据恢复过程：

Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存，一般情况下1GB的快照文件载入到内存的时间约为20~30秒钟。

RDB快照过程：

① Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）。

② 父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入到磁盘中的临时文件。

③ 当子进程写入完所有数据后会用该临时文件替换旧的RDB文件。

RDB文件的压缩：

RDB文件可以通过 rdbcompression参数来禁用压缩的。

快照需要注意的问题：

由于redis使用fork复制一份当前进程，那么子进程就会占有和主进程一样的内存资源，譬如主进程8G的内存，那么在备份的时候，必须保证有16G的内存，要不然就会启用虚拟内存，性能变差。

3.redis持久化之AOF

AOF方式是以日志的形式来记录每个写操作。将redis执行过的所有写指令都记录下来，读操作不记录。文件可以追加但是不可以修改文件。redis启动之时会读取文件重新构建数据。如果redis重启的话，将之前的写指令的操作，从头到尾恢复一遍完成备份。

默认是关闭的。

当aof方式和rdb方式共存的时候，先加载aof方式。

优化AOF文件：

使用 BGREWRITEAOF命令来重写aof文件。就是去除了数据的中间执行过程，保留最终数据命令即可。

重写AOF文件的方式：

auto-aof-rewrite-percentage 100

当前AOF的文件大小超过了上一次重写时的AOF文件大小的百分之多少时会再次进行重写。如果之前没有重写过，那么则以启动时的AOF文件大小为依据。

auto-aof-rewrite-min-size 64MB

限制了允许重写的最小AOF文件大小，通常在AOF文件很小的时候即使其中有些冗余的命令也是可以忽略的。

文件同步的配置：

appendfsync always : 同步持久化，每次发生数据变更就被立即记录到磁盘。性能比较差，但是数据完整性比较好。

appendfsync everysec : 出厂默认推荐，异步操作，每秒往磁盘写入一次，如果一秒内出现宕机，数据就会丢失。在性能和持久化方面最了很好的折中

appendfsync no : 完全依赖操作系统，性能好的时候就持久，不好的时候就不持久化。

AOF同步的问题：

文件写入默认情况下会先写入系统缓存中，系统每30秒同步一次，才是真正的写入到了磁盘。即使每秒做文件同步也可能导致数据的丢失。

AOF方式出现异常的修复：redis-check-aof-fix appendonly.aof