Redis基础知识3-持久化

• 注意: 撰写本文目的主要是为了给自己做一个备忘录，如果你学过Redis并且希望从本文中找到一些忘记的知识点，那么你可以阅读本文章。由于文章内讲解并不是很多，因此此文章并不适合小白入门使用。

1.Redis简介

• 官网介绍：
  在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里。
• Redis是什么：
  Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何**IO操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是很敏感，那RDB方式要比AOP方式**更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
• Fork：
  Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

2.RDB(Redis DataBase)

RDB存储：

• RDBRedis会将数据存储在dump.rdb文件中。
• 如果使用shutdown或者系统突然崩溃或关机使得Redis突然停止工作时，Redis会将此时表中的数据保存至dump.rdb文件中，执行一次save操作。
• 当满足save条件时（规定时间内操作了指定次数：插入、删除、更新，不包括get），Redis会将表中的数据保存至dump.rdb文件中，也会执行save操作。save操作执行条件如下（save 秒钟 写操作次数）：
  

Redis.conf中Snapshot相关配置:

• 直接输入save可以立即执行备份。

禁用：

• 如果想禁用RDB持久化策略，只要不设置任何save指令，或者给save传入一个空字符串也可以

Stop-writes-on-bgsave-error

rdbcompression压缩

如何触发RDB快照：

• 配置文件中默认的快照配置。
  冷拷贝直接使用，可以cp dump.rdb dump_new.rdb
• 命令save或是bgsave。
  1.Save：save时只管保存，其他不管，全部阻塞。
  2.BGSAVE：Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
• 执行flushall命令，也会产生dump.rdb文件，但里面是空的，无意义。

如何恢复：

• 将备份文件（dump.rdb）移动到redis安装目录并启动服务即可。
• CONFIG GET dir获取目录。

优势：

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

劣势：

• 在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会失去最后一次快照后的所有修改。
• Fork的时候，内存中的数据被克隆了一份，大致2倍的碰着性需要考虑。

如何停止：

• 动态所有停止RDB保存规则的方法：redis-cli config set save ""

3.AOF(Append Only File)

3.1.是什么

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

3.2.AOF配置文件

3.3.注意事项

• 自动生成的aof配置文件最后会有FLUSHALL指令，即加载完所有的数据恢复工作之后，会执行FLUSHALL清空指令。
• 若AOF配置中包含非法语句，则Redis-server会启动失败。此时，可以使用redis-check-aof --fix 文件名称来排查文件中的错误。

3.4.配置位置

• appendonly no：默认是no，yes就打开aof持久化。

3.5.APPEND ONLY MODE追加

• appendonly：
• appendfilename：
• Appendfsync：
  1.Always：同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差且数据完整性比较好。
  2.Everysec：出厂默认推荐，异步操作，每秒纪录 如果一秒内宕机，有数据丢失。
  3.No**
• **No-appendfsync-on-rewrite ：**重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。
• **Auto-aof-rewrite-min-size：**设置重写的基准值
• **Auto-aof-rewrite-percentage：**设置重写的基准值

3.6.AOF启动/修复/恢复

• 正常恢复：
  1.启动：修改默认的appendonly no.，改为yes。
  2.将所有数据的aof文件复制一份保存到对应目录（config get dir）
  3.恢复：重启redis然后重新加载
• 异常恢复：
  1.启动：设置Yes
  2.备份被写坏的AOF文件
  3.Redis-check-aof --fix进行修复
  4.重启redis然后重新加载

3.7.Rewrite

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

重写原理

• AOF文件持续增长而过大时，会fork出一条新进程来将文件重写（也是先写临时文件最后再rename），遍历新进程的内存中数据，每条记录有一条的Set语句，重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

触发机制

• Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

3.8.优势

• 每秒同步：appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差且数据完整性比较好。
• 每修改同步：appendfsync everysec 出厂默认推荐，异步操作，每秒纪录 如果一秒内宕机，有数据丢失。
• 不同步：appendfsync no 从不同步

3.9.劣势

• 相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
• Aof运行效率要慢于rdn，每秒同步策略效果较好，不同步效率和rdb相同

3.10.总结

性能建议：