reids（5）：持久化

redis持久化有两种:RDB和AOF

一：RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发方式有手动和自动

手动触发命令：save和bgsave

save:阻塞当前redis服务器，直到RDB过程完成为止，对于内存比较大的实例，线上不建议使用。

bgsave：redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束，阻塞只发生在fork阶段，时间很短。

自动化：（1）使用save相关配置，save m n

              （2）从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点

             （3）执行debug reload命令重新加载redis时，自动触发save操作。

             （4）默认情况下执行shutdown命令，如果没有开启AOF持久化功能自动执行bgsave。

bgsave流程：

RDB文件：

保存：RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定。可以通过执行config set dir{newDir}和config set dbfilename{newFileName}运行期动态执行，当下次运行时RDB文件会保存到新目录。

压缩：Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数config set rdbcompression{yes|no}动态修改。

校验：如果Redis加载损坏的RDB文件时拒绝启动，这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告。

RDB优缺点：

优点：RDB是一个紧凑压缩的二进制文件，适合用于备份，全量复制等场景，用于灾难恢复。速度远快与AOF方式

缺点：无法实时持久化、秒级持久化，重量级操作。二进制文件版本多，不利于兼容。

二：AOF

AOF以独立日志的方式记录每次写命令，重启时重新执行AOF文件中的命令达到恢复数据的目的，主要作用是解决了实时持久

化。

开启AOF配置：appendonly yes，默认不开启，aof文件名通过appendfilename配置，默认appendonly.aof。保存路径与RDB一样。

流程：

1，写入命令追加到aof_buf缓冲区中。

2，做同步操作

3，AOF文件会越来越大，所以需要定期重写，到达压缩目的。

4，服务器重启时就可以加载AOF文件进行数据恢复。

命令写入：

AOF命令写入采用的是文本协议格式，原因：1，兼容性。2，避免二次开销，3，可读性，方便修改和处理。

AOF命令先追加到缓存区的原因：如果直接写入硬盘，那性能也要考虑硬盘的性能，不保证性能。

文件同步：

重写机制：

随着写入命令越来越多，AOF文件会越来越大，所以需要重写机制来缩小文件大小。1超时的不写入，2无效的不写入，3多条合并一条命令。

手动触发：直接调用bgrewriteaof命令，

自动触发：根据auto-aof-rewrite-min-size（重写时文件最小体积）和auto-aof-rewrite-percentage（当前文件空间和上一次重写后的文件空间的比值）参数确定自动触发时机。

重启加载：