redis的持久化方式(RDB,AOF)

Redis提供了一系列不同的持久性选项：(这些官方文档有翻译过来就是这个)
RDB持久性以指定的间隔执行数据集的时间点快照。
AOF持久性记录服务器接收到的每个写操作，这些操作将在服务器启动时再次播放，从而重建原始数据集。命令使用与Redis协议本身相同的格式，以仅附加的方式记录。Redis可以在日志太大时在后台重写日志。
RDB持久化时redis会单独(fork)出一个子进程,会先将数据写入到一个临时文件中,持久化完成后再替换掉上次持久化好的文件.这里设置完快照时间后在redis关闭或者达到快照时间后生成dump.rdb文件,恢复数据只需要把dump6379.rdb文件移动到redis安装目录下,并且启动redis服务即可恢复数据
fork的作用是复制一个与当前进程一样的进程.新进程的所有数据(变量,环境变量,程序计算器等),数值和原进程一致,但是是一个全新的进程,并且作为原进程的子进程

image.png

#RDB持久化可以通过设置快照时间也可以通过直接传一个空字符串
save
#RDB动态所有停止RDB保存规则
redis-cli config set save ""
#记住这里在关闭redis之前执行了flushall命令则rdb文件为空,因为redis执行flushall命令直接斩断与内存的联系再生成rdb文件所以为空

image.png

RDB优势和劣势
优势:适合大规模数据的恢复,对数据的完整性和一致性要求不高
劣势:在一点间隔内进行备份,如果redis意外down掉的话就会丢失最后一次快照的数据,fork的时候,内存中的数据被克隆一份,大致膨胀了两倍
RDB持久化总结

image.png

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

image.png

AOF正常恢复,将有数据的aof文件复制一份保存到对应目录(config get dir)下,重启redis后重新加载
异常恢复:通过Redis-check-aof --fix命令来修复已破坏的aof文件

AOF的重写(REwrite),AOF采用文件追加方式,文件会越来越大为避免出现此情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,也可以使用bgrewriteaof
例子:

#通过redis来set同一个key的值
set k1 10 set k1 15 .....set k1 100
就会压缩成一句  set k1 100

Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次重写的一倍且文件大于64MB时触发

image.png

AOF 的优势和劣势
优势:每秒修改同步,每秒同步,不同步,从这三种中选取一种
劣势:相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb,AOF运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同

image.png

AOF总结:

image.png

二者选其一:
首先看官方建议:RDB持久化方式能够在指定时间间隔能对你的数据进行快照存储
AOF 持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据AOF命令以redis协议追加保存每次写的操作到文件末尾.
Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
如果只做缓存:可以不使用任何持久化操作

image.png

同时开启两种持久化方式:在这种情况下,当redis重启的时候会有限载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据要比RDB保存的数据更加完整
RDB的数据不实时,同时使用两者服务器重启也只会找AOF文件.只使用AOF的话,因为AOF文件在不断的变化不好备份.所以RDB更适合用于备份数据库.
性能建议:

因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。
如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。新浪微博就选用了这种架构