1、持久化

服务器意外断电或者软件崩溃，等一切恢复后，经常看到一些自动恢复文件：

这其中的过程就是内存和磁盘之间的数据保存：

持久化：

利用永久性存储介质将数据进行保存，在发生意外时将保存的数据进行恢复的工作机制称为持久化。

持久化机制可以防止数据的意外丢失，确保数据安全性。

2、持久化的思路

将当前数据的状态进行保存，快照的形式，在Redis中称RDB
将操作过程进行保存，日志的形式（类比ctrl+z与ctrl+y），在Redis中称AOF

3、RDB

3.1 RDB-save

指令：save
作用：手动保存一次数据

RDB在redis.conf中的相关的配置：

dbfilename dump.rdb
这里规定了save后保存的文件名，长设置为dump-端口号.rdb
dir
文件保存位置，包含日志文件、持久化文件，常设置成空间较大的目录，目录起名data
rdbcompression yes
设置存储至本地数据库时是否压缩数据，默认为 yes，采用 LZF 压缩。设置为no，可以节省 CPU 运行时间，但会使存储的文件变大（巨大）
rdbchecksum yes
设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行。通常默认为开启状态，如果设置为no，可以节约读写性过程约10%时间消耗，但是存储一定的数据损坏风险

***以下模拟验证save的效果：
//添加数据并save
set name 9527
save

//杀掉对应进程模拟故障
ps -ef |grep -i redis
kill -s 9  26862  

//连接Redis，查看数据name依然存在
keys *

注**

由于是单线程，save指令的执行会阻塞当前Redis服务器，直到当前RDB完成，可能造成长时间阻塞，不建议线上环境用。

3.2 RDB-bgsave

指令：bgsave
作用：手动发起保存操作，Redis保存了这个操作，不立即执行，在合适的时候执行。

127.0.0.0:6379 > bgsave
Background saving started

bgsave执行后如下：若daemonize yes，则日志中可看到返回消息，若daemonize no，则控制台可看到返回消息。

bgsave在redis.conf中的相关的配置参数：

除了save的四个外，bgsave还有其特有的stop-writes-on-bgsave-error yes，即后台存储过程中如果出现错误现象，是否停止保存操作，常为yes

3.3 RDB自启动–save配置

如何实现当满足某些条件时，让redis服务器发起RDB指令？

save配置

配置
save second changes

作用
在限定的时间范围内，key的变化(增减)数量达到指定值即进行持久化

参数
second：监控的时间的范围
changes：监控周期内key的变化量

位置
conf文件中进行配置

示例
save 900 10
900秒之内key变化了十个，就存一次

save配置的原理图：

注意：

不进行数据比对，即两次set改同一个东西，也认为是两个key发生变化了
save配置启动后执行的是bgsave操作
配置的频度过高或者过低都会出现性能问题，要结合实际业务进行设置

3.4 RDB的特殊启动方式

全量复制
服务器运行过程中重启：debug reload
关闭服务器时指定保存数据：shutdown save

RDB三种启动方式的对比（dbsave和save配置文件一样）

RDB优点：

RDB文件是一个紧凑压缩的二进制文件，存储效率高
RDB存储的是数据快照，适用于数据备份、全量复制等场景
RDB恢复数据的速度比AOF快很多
应用：服务器中每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复

RDB缺点：

无法实时持久化，有可能丢数据
RDB基于快照思想，每次读写都是全部数据，数据量巨大时，效率很低
bgsave的运行要执行fork操作创建子进程，会损失一点性能
Redis众多版本中rdb文件格式不统一，可能有数据格式不兼容现象

4、AOF

AOF(append onlyfile)持久化：

以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF解决了持久化实时性的问题，是Redis持久化的主流方式。

4.1 AOF持久化数据三种策略(appendfsync)

always(每次)
每次操作都同步到.aof文件中，数据零误差但性能损失太大

everysec(每秒)
每秒将缓冲区的指令同步到.aof文件中，数据准确性较高，性能较高，系统宕机损失1秒数据

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

4.2 AOF相关配置

修改redis-6379.conf：

# AOF功能开启
appendonly yes
# 选择策略
appendfsync always|everysec|no
# 配置AOF持久化的文件名,默认为appendonly.aof,常用appendonly-端口号.aof
appendfilename filename
# 持久化文件的保存路径,和RDB一样
dir

4.3 AOF重写

面对以下场景，不再应该单纯的记录三条set指令，这对后续数据恢复无意义。

AOF重写就是将对同一个数据的若干条指令，按照最终执行的结果转化成对应的指令进行记录。这样既能降低磁盘占用，也能提高数据恢复的效率。

AOF重写方式--手动重写

手动重写指令：
bgrewriteaof
其执行的流程图如下：

AOF重写方式--自动重写

自动重写触发条件设置一
auto-aof-rewrite-min-size size
对比参数：
aof_current_size
触发条件：
aof_current_size>auto-aof-rewrite-min-size size时触发自动重写机制

自动重写触发条件设置二
auto-aof-rewrite-percentage percent
对比参数：
aof_base_size
触发条件：

aof_current_size和aof_base_size这两个对比参数可以通过指令info查看。也可通过配置文件修改。