Redis持久化

Redis持久化

一、RDB (快照)

1、RDB启动方式——save指令
命令：

save

作用：
手动执行一次保存操作。save指令执行后，会在指定的文件下，生成一个rdb后缀的文件，该文件即二进制保存的数据库数据。

2、save指令,相关conf配置项

dbfilename dump.rdb
说明：设置本地数据库文件名，默认值为dump.rdb
经验：通常把文件名设置为dumb-端口号.rdb

dir
说明：设置存储.rdb文件和日志文件的路径
经验：通常建一个名data的文件夹统一存储

rdbcompression yes
说明：设置存储数据到本地时是否要压缩数据，默认为yes,采用LZF压缩
经验：通常选择开启状态，如果选择no会减少CUP时间，但是会增大内存消耗

rdbchecksum yes
说明：设置是否进行rdb文件格式检验,该检验过程在读写过程均进行
经验：通常默认为开启状态，如果设置为no，可以节省10%的读写时间消耗，但是存在数据损坏风风险。

save指令是马上执行，并将此任务加入到任务序列，会阻塞当前Redis服务器（Redis是单线程的），直到RDB过程完成为止，如果保存数据过大有可能会造成长时间阻塞，线上环境不适合使用。实际上save指令也不会被使用，用下面的bgsave即可

.
2、RDB启动方式——bgsave指令
命令:

bgsave

作用：手动启动后台保存当前数据，但不是立即执行
bgsave是命令是针对save指令阻塞做出的优化，其通过fork函数生成子进程去创建rdb文件。

3、RDB启动方式——save配置
配置内容：

save second changes

作用：
满足限定时间内key的变化数量达到指定数量则进行持久化。

参数：
second:监控时间
changes:监控key的变化量

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

注意：

RDB缺点，不能实时记录所有数据，宕机容易造成数据丢失。

二、AOF（只追加文件）

相比于RDB，AOF以独立日志的方式记录每次写的命令，重启时，再重新执行日志中的命令，从而恢复数据。

1、AOF写数据的三种策略：

1.1、always(每次)
每次写入操作均同步到AOF文件中，数据零误差，性能较低，不推荐。

1.2、everysec(每秒)
每秒将缓冲区的指令同步到AOF文件中，数据准确度较高，性能较高，推荐使用，Redis默认就是这个策略，最多丢失一秒的数据。

1.3、no(系统控制)
由操作系统自己控制每次把缓冲区指令同步到AOF文件的周期，整体过程不可控。

2、开启AOF持久化
Redis默认是没有开启AOF持久化的，我们需要在conf配置文件中开启

配置：

appendonly yes|no

作用：
是否开启AOF持久化，默认下不开启

配置：

appendfaync  always | everyec | no

作用：
配置AOF写数据的策略

配置：

appendfilename redis.aof

作用：配置生成的aof文件名称

3、AOF重写

随着AOF记录的指令越来越多，文件会越来越大，为了解决这个问题，Redis引用了AOF重写机制压缩文件体积。重写机制就是将内存中redis数据再转化成写命令，同步到一个新的AOF文件中，旧的则被取代。简单来说就是将若干个命令执行的结果数据对应的最简指令记录下来。

AOF重写作用：
1、降低磁盘占用量，提高利用率。
2、提高持久化效率，降低持久化写时间，提高IO性能。
3、降低恢复数据的时间，提高恢复效率。

AOF重写规则：
1、进程中已超时的数据不再写入文件
2、忽略无效指令，重写时使用进程内数据直接生成。
3、对同一数据的多条写命令合并为一条命令，另外为了防止客户端缓冲区溢出，对list，set,sort_set,hash等数据，每条指令最多一次写入64个元素。

RDB和AOF两种持久化方式对比：

建议同时开启两种方式。
千万不要先开启RDB，过一段时间再开启AOF，由于AOF优先级更高，AOF文件恢复的数据会覆盖掉RDB的数据！！！！此时由于大部分数据再RDB，AOF刚创建只有少部分数据，AOF覆盖掉RDB，就会丢失大量数据了！！！