redis的持久化配置：
主要包括两种方式：1.快照 2 日志
来看一下redis的rdb的配置选项和它的工作原理：
1 save 900 1 // 表示的是900s内，有1条写入，则产生快照 2 save 300 1000 // 表示的是300s内，有1000次的写入，则产生快照 3 save 60 10000 // 表示的是60s内，有10000次的写入，则产生快照 4 （这3个选项都屏蔽，则rdb被禁用） 5 6 stop-writes-on-bgsave-error yes // 后台dump备份进程出错的时候，主进程停止不停写入？ 7 8 rdbcompression yes // 导出的rdb文件是否需要压缩 9 10 rdbchecksum yes //导出的rdb恢复时数据要不要检验rdb的完整性 11 12 dbfilename dump.rdb //导出来的rdb文件名 13 dir ./ //rdb的放置路径
上面的就是rdb的常用配置，那它的备份原理是啥？
非常的简单，只要满足上面的save的3个条件中的任何一条，都会直接从内存中dump出一份镜像到磁盘上，速度非常的快
那我们考虑，如果我们在某一个时刻set存入一条数据，那这时突然redis宕机，那这个时候我们set的数据就会丢失，这是它的一个弊端，就是在发生一些异常的情况的时候，我们可能会丢失1-n分钟内的数据
那我们接下来看一下aof日志的一些配置和原理，它解决了上面rdb不能解决的一些问题：
同样，还是来看一下相关的配置内容：
1 appendonly no # 是否打开 aof日志功能 2 3 appendfsync always # 每1个命令,都立即同步到aof. 安全,速度慢 4 appendfsync everysec # 折衷方案,每秒写1次 5 appendfsync no # 写入工作交给操作系统,由操作系统判断缓冲区大小,统一写入到aof. 同步频率低,速度快, 6 7 8 no-appendfsync-on-rewrite yes: # 正在导出rdb快照的过程中,要不要停止同步aof 9 auto-aof-rewrite-percentage 100 #aof文件大小比起上次重写时的大小,增长率100%时,重写 10 auto-aof-rewrite-min-size 64mb #aof文件,至少超过64M时,重写
那我们开启了aof的日志的功能的时候，这时候我们每一次进行操作，aof就会将所有的操作记录到aof的日志中，我们可以通过appendfsync和我们具体的业务场景来具体指定多长时间写入文件，当然了推荐是everysec，那这样的话，由于我们记录的是每隔一秒的操作，那如果redis突然宕机的话，我们可以通过aof来恢复数据，这样的话就解决了上述rdb出现的数据丢失的问题，当然了这也会丢失大概1秒的数据吧，损失就会降低很多
我们来看一下相关的问题：
1 注: 在dump rdb过程中,aof如果停止同步,会不会丢失? 2 答: 不会,所有的操作缓存在内存的队列里, dump完成后,统一操作. 3 4 注: aof重写是指什么? 5 答: aof重写是指把内存中的数据,逆化成命令,写入到.aof日志里. 6 以解决 aof日志过大的问题. 7 8 问: 如果rdb文件,和aof文件都存在,优先用谁来恢复数据? 9 答: aof，不会使用rdb来进行恢复数据 10 11 问: 2种是否可以同时用? 12 答: 可以,而且推荐这么做 13 14 问: 恢复时rdb和aof哪个恢复的快 15 答: rdb快,因为其是数据的内存映射,直接载入到内存,而aof是命令,需要逐条执行