前言

redis是一个内存数据库，当redis服务器重启，获取电脑重启，数据会丢失，我们可以将redis内存中的数据持久化保存到硬盘的文件中。
redis提供两种持久化方式:

RDB：快照，通过从服务器保存和持久化
AOF：日志，操作生成相关日志,并通过日志来恢复数据。couchDB对于数据内容,不修改,只追加,则文件本身就是日志,不会丢失数据.
注意：redis默认开启了RDB持久化

一、RDB模式

在指定的时间间隔内将内存中的数据快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里,Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。

Ps：fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程，在每次redis服务器启动的时候，会自动把dump.rdb这个文件的键值对全部读取到内存

操作步骤如下：

第1步：设置RDB模式

编辑redis.conf文件，命令如下

cd /usr/local/bin
vi redis.conf

RDB快照相关参数说明：

	save 900 1    #刷新快照到硬盘中，必须满足两者要求才会触发，即900秒之后至少1个关键字发生变化。
	save 300 10  #必须是300秒之后至少10个关键字发生变化。
	save 60 10000 #必须是60秒之后至少10000个关键字发生变化。
	上面三个参数屏闭后，rdb方式就关闭了
	
	stop-writes-on-bgsave-error yes    #后台存储错误停止写。
	rdbcompression yes    #使用LZF压缩rdb文件。
	rdbchecksum yes    #存储和加载rdb文件时校验。
	dbfilename dump.rdb    #设置rdb文件名。
	dir ./    #设置工作目录，rdb文件会写入该目录。

以下图片截自默认的redis.conf文件设置
在这里插入图片描述

第2步：重启redis查看数据是否存在

先删除dump.rdb
使用客户端连接并添加数据
杀掉redis进程

pkill -9 redis

启动redis查看数据是否存在

Tip: RDB的缺陷:在2个保存点之间断电，将会丢失1-N分钟的数据，所以出于对持久化的更精细的要求，redis增添了aof的方式 append only file 持久化数据

二、AOF模式

思路：可以设置数据的追加频次，比如内存每写一条，就备份一条，也可以按照时间间隔，比如每1秒钟就备份一次
缺点：文件大，写操作频繁。

Tips：

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

第1步：设置RDB模式

编辑redis.conf文件，命令如下

cd /usr/local/bin
vi redis.conf

AOF日志相关参数:

	appendonly no # 是否打开aof日志功能  no:不开启   yes:开启日志
	appendfsync always   # 每1个命令,都立即同步到aof. 安全,速度慢
				everysec # 折衷方案,每秒写1次
				no      # 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快
	no-appendfsync-on-rewrite  yes: # 正在导出rdb快照的过程中,要不要停止同步aof

如果要更改持久化方案为aof模式，可以按照以下图片来设置
在这里插入图片描述

第2步：重启redis查看aof文件

保存退出并杀掉redis进程

pkill -9 redis

在这里插入图片描述

打印日志文件内容

more /usr/local/bin/appendonly.aof

在这里插入图片描述

三、关于持久化的总结

RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾，Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大
只做缓存：如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式.
同时开启两种持久化方式
在这种情况下,当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库(AOF在不断变化不好备份)，快速重启，而且不会有AOF可能潜在的bug，留着作为一个万一的手段。
性能建议
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1这条规则。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文件，载入较新的那个。新浪微博就选用了这种架构

扩展1、AOF重写

思考：如果对同一个key进行多次操作，在aof日志中怎样表现操作记录，一条还是n条？

1.1、案例：创建age并改变五次值

在这里插入图片描述

问：日志会将每一步操作都记录，如果要对一个key操作多次，在数据上的表现只有一个但在日志中会有n条记录。当数据丢失需要找回数据的时候怎样找到正确的值？
答：aof重写是将内存中的key和value逆化为redis命令重新保存到日志中，就好像是将所执行的操作做了一个总结。

1.2、设置AOF重写的相关参数

编辑redis.conf文件，命令如下

cd /usr/local/bin
vi redis.conf

可以调整如下参数：

aof重写相关参数:
	auto-aof-rewrite-percentage 100 #aof文件大小比起上次重写时的大小,增长率100%时,重写
	auto-aof-rewrite-min-size 64mb #aof文件,至少超过64M时,重写

扩展2、关于aof的问答环节

问: 在dump rdb过程中,aof如果停止同步,会不会丢失?

答: 不会,所有的操作缓存在内存的队列里, dump完成后,统一操作.

问: aof重写是指什么?

答: aof重写是指把内存中的数据,逆化成命令,写入到.aof日志里.以解决 aof日志过大的问题.

问: 如果rdb文件,和aof文件都存在,优先用谁来恢复数据?

答: aof

问: 2种是否可以同时用?

答: 可以,而且推荐这么做

问: 恢复时rdb和aof哪个恢复的快

答: rdb快,因为其是数据的内存映射,直接载入到内存,而aof是命令,需要逐条执行

扩展3、面试怎么说？

3.1、RDB（Redis DataBase）

        通过快照将某一时刻的所有数据写入磁盘，这是redis默认使用的持久化方案，保存的文件是以.rdb形式为后缀（默认的文件名为dump.rdb），因此这种文件被称为RDB文件；
        RDB提供了两种方式持久化数据，分别是save和bgsave，save是阻塞的，当执行缓存时不再接受客户端的命令；bgsave是非阻塞的，当执行缓存时系统会fork一个子进程进行持久化，这不会影响处理客户端的命令，由于是异步操作，所以在进行持久化过程中，如果此时客户端写入了数据，这些数据将不会被持久化。
        我们可以在redis.conf配置文件中通过save属性设置自动触发，save有两个参数m、n，表示每m秒内至少有n个key的值发生变化时触发，比如save 60, 10000，则表示在60秒内有一万个key值发生变化时进行RDB操作。