<Redis> 入门五 持久化RBD/AOF

RDB

　　RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘(默认是 dump.rdb)。

　　默认持久化机制，就是将内存中的数据以快照的方式写入二进制文件dump.rbd中。

　　触发快照的条件

　　　　1.自己配置快照规则

　　　　　　save <second> <exchanges>

　　　　　　second 秒内，key的修改数量大于exchanges时，执行快照

　　　　　　save的关系是或的关系，都满足

　　　　　　

　　　　　　默认文件名为 dump.rdb

　　　　　　默认路劲为配置文件下的当前路径

　　　　　　

　　　　　　获取配置文件中的快照规则 config get save

　　　　　　添加新规则，服务器重启后失效，config set save "second exchanges"

　　　　　　

　　　　2.save或bgsave

　　　　　　save：执行内存的数据同步到磁盘的操作，这个操作会阻塞客户端的请求。（不要轻易执行，数据量大，阻塞时间差）

　　　　　　bgsave：在后台异步执行快照操作，这个操作不会阻塞客户端的请求。

　　　　3.执行flushall

　　　　　　清除内存中的所有数据，只要快照规则不为空，那么redis就会执行快照。

　　　　　　

　　　　4.执行复制的时候（集群）

　　快照的实现原理

　　　　redis会使用fork函数复制一份当前进程的副本（子进程）

　　　　父进程继续处理客户端请求。

　　　　fork进程负责把内存的数据同步到磁盘的临时文件，当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

　　　　缺点：由于子进程是复制父进程，两个内存大小相同的redis进程在系统上运行，会造成内存使用率大幅增加。

　　使用rdb的优缺点

　　　　优点：

　　　　　　1.只包含一个dump.rdb文件，方便备份移动。

　　　　　　2.rdb回复大数据集的速度比aof快。

　　　　　　3.rdb可以最大化redis性能，因为是子进程去处理保存工作，父进程无需执行io操作。

　　　　缺点：

　　　　　　1.rbd的规则是单位时间内改变多少个键，才会触发，而在为改变之前，一旦服务器故障，就会丢失几分钟的数据

　　　　　　2.当数据量大时,fork子进程会非常耗时，会造成服务器在某毫秒或长达一秒的时间停止处理客户端。并且子进程和父进程两个进程会消耗更多的内存。

AOF

　　redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。

　　如何配置

　　　　appendonly 改为yes

　　　　appendfilename：保存的文件名

　　　　

　　　　当修改了值后，可以看到生成了新的文件appendonly.aof

　　　　

　　　　vim appendonly.aof文件，可以看到每条记录都被写入aof文件中

　　　　

　　同步磁盘数据出现的问题

　　　　redis每次更新数据时，aof机制都会将命令写入aof文件中。

　　　　但是实际上由于操作系统的缓存机制，数据并没有实时写到磁盘，而是先写入磁盘的缓冲区，再通过硬盘缓存机制刷新保存到文件中。

　　　　这样就可能回出现数据丢失。

　　配置同步策略

　　　　appendfsync always：每次收到命令就立刻强制写入磁盘，最慢，但是完全持久化，不推荐使用

　　　　appendfsync everysec：每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐

　　　　appendfsync no　　：完全依赖os，性能最好，持久化没保障。

　　　　

　　　　每一秒都将命令写入文件中，aof文件越来越大，并且很多语句会出现多余，所以引入了重写策略。

　　重写策略（优化aof文件）

　　　　auto-aof-rewrite-percentage 100 ：当aof文件大小超过上一次aof文件大小的百分之多少会重写。如果之前没重写过，以启动时aof文件大小为准。

　　　　auto-aof-rewrite-min-size 64mb ：限制允许重写最小aof文件大小，也就是文件大小小于64mb，不需要进行优化。

　　　　

　　重写的实现原理

　　　　1.redis调用fork函数，复制一个子线程

　　　　2.父进程继续处理client请求，将请求追加到aof文件，同时收到的命令缓存起来，这样保证子进程重写失败不会出问题。

　　　　3.子进程根据内存中的数据快照，往临时文件中写入重建数据库状态的命令

　　　　4.当子进程将快照的命令写入临时文件后，通知父进程，然后父进程把缓存的写命令也写入临时文件

　　　　5.当父进程写完后，将临时文件替换老的aof文件，后续命令往新的aof文件中追加

　　aof文件的修复

　　　　1.先复制原有的aof   cp appendonly.aof   appendonly.aof.bak

　　　　 2.执行 redis-check-aof --fix appendonly.aof 完成修复

　　aof的优缺点

　　　　优点：　　

　　　　　　1.aof的同步策略，可以让aof安全性变的非常高，并且使用每秒同步一次，redis依然可以保证很好的性能，就算发生故障，也最多只丢失一秒的数据。

　　　　　　2.aof采用末尾追加的方式写入文件，即便出现问题，aof-check-aof也可以修复文件。同时aof提供了重写策略，来优化aof文件

　　　　　　3.aof有序保存了对数据库执行写的操作，以redis协议数据保存，易于读和解析，并且不小心执行了flushall，也可以移除aof文件末尾的flushall命令，恢复之前的状态。

　　　  缺点：

　　　　　　1.对于相同的数据集来说，aof文件体积大于rdb文件的体积。

　　　　　　2.因为采用了同步策略，aof的速度相比rdb还是要慢一些。

　　两种持久化的策略可以同时使用，也可以使用其中的一种，如果同时使用的时候，那么Redis重启时，会优先使用aof文件来还原数据。