Redis的数据持久化方案

前言

RDB方式

概述：

1.RDB手动

２.RDB自动

　RDB优缺点

AOF方式

概述

AOF写数据的三种策略

AOF相关配置

AOF重写

AOF重写方式

手动重写 bgrewriteaof

自动重写

总结

前言

Redis是一个内存型数据库，也就是说如果不将内存中的数据保存到磁盘，那么服务器进程一旦退出，服务器中的数据也会随之消失，因此redis提供了两种方式供我们进行数据持久化操作。

RDB方式：该方式关注数据本身，它将当前数据进行保存，类似于快照，用于存储数据结果，存储格式简单
AOF方式：该方式关注数据的操作过程，它将数据的操作过程以日志的形式进行保存，实现数据持久化

RDB方式

概述：

在指定的时间间隔内，将内存中的数据集快照写入磁盘，恢复时将快照文件直接读到内存中

RDB快照有两种方式，即手动和自动，下文依次介绍

1.RDB手动

save指令

命令 :save

作用 :手动执行一次保存操作

save指令相关配置

dbfilename dump.rdb

说明：设置本地数据库文件名，默认值为 dump.rdb

经验：通常设置为 dump-端口号.rdb

dir

说明：设置存储.rdb文件的路径

经验：通常设置成存储空间较大的目录中，目录名称data rdbcompression yes

rdbcompression yes

说明：设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF算法压缩

经验：通常默认为开启状态，如果设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）

rdbchecksum yes

说明：设置是否进行CRC64算法RDB文件格式校验，该校验过程在写文件和读文件过程均进行

经验：通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险

save指令工作原理(单线程任务执行序列)

客户端1 127.0.0.1:6379>set key1 value1

客户端2 127.0.0.1:6379>set key2 value2

客户端3 127.0.0.1:6379>save

客户端4 127.0.0.1:6379>get key

对redis数据库执行4此指令顺序===> set set save get

注意：save指令的执行会阻塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用

bgsave指令

命令：bgsave

作用：手动启动后台保存操作，但不是立即执行

bgsave指令工作原理

注意： bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。

Fork

Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程

２.RDB自动

配置：save second changes

作用 : 满足限定时间范围内key的变化数量达到指定数量即进行持久化

参数 :

second：监控时间范围

changes：监控key的变化量

位置 : 在conf文件中进行配置

注意：

save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的
save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系
save配置启动后执行的是bgsave操作

　RDB优缺点

RDB是一个紧凑压缩的二进制文件，存储效率较高
RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
RDB恢复数据的速度要比AOF快很多 RDB节省磁盘空间
Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能
RDB方式无论是执行指令还是利用配置，无法做到实时持久化，具有较大的可能性丢失数据
Redis的众多版本中未进行RDB文件格式的版本统一，有可能出现各版本服务之间数据格式无法兼容现象

AOF方式

概述

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的；与RDB相比可以简单描述为改记录数据为记录数据产生的过程AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

AOF写数据的三种策略

always(每次）

每次写入操作均同步到AOF文件中，数据零误差，性能较低

everysec（每秒）

每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高在系统突然宕机的情况下丢失1秒内的数据

no（系统控制）

由操作系统控制每次同步到AOF文件的周期，整体过程不可控

AOF相关配置

配置：appendonly yes|no

作用：是否开启AOF持久化功能，默认为不开启状态

配置：appendfsync always|everysec|no

作用：AOF写数据策略

配置：appendfilename filename

作用：AOF持久化文件名，默认文件名未appendonly.aof，建议配置为appendonly-端口号.aof

配置：dir

作用：AOF持久化文件保存路径，与RDB持久化文件保持一致即可

AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录

AOF重写作用

降低磁盘占用量，提高磁盘利用率
提高持久化效率，降低持久化写时间，提高IO性能
降低数据恢复用时，提高数据恢复效率

AOF重写规则

进程内已超时的数据不再写入文件
忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令如del key1、 hdel key2、srem key3、set key4 111、set key4 222等
对同一数据的多条写命令合并为一条命令
如lpush list1 a、lpush list1 b、 lpush list1 c 可以转化为：lpush list1 a b c。
为防止数据量过大造成客户端缓冲区溢出，对list、set、hash、zset等类型，每条指令最多写入64个元素
AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

AOF重写方式

手动重写 bgrewriteaof

自动重写

触发机制

Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发;重写虽然可以节约大量磁盘空间，减少恢复时间。

何时重写

每次重写操作对cpu来说都是有负担的，因此设定Redis要满足一定条件才会进行重写= auto-aof-rewrite-min-size 设置重写的基准值，最小文件64MB。达到这个值开始重写。 auto-aof-rewrite-percentage 设置重写的基准值,文件达到100%时开始重写（文件是原来重写后文件的2倍时触发)