redis持久化（persistent）

什么是持久化（persistents）

利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。
持久化是为了防止数据的意外丢失，确保数据安全性

持久化过程中保持的是什么

想了解更多RDB月AOF之间的区别请看这篇文章：https://www.cnblogs.com/zxs117/p/11242026.html

RDB持久化

RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。

RDB save指令

redis给我们提供了save指令来实现RDB模式的持久化操作，执行这个命令会在指定目录下生成一个db文件，里面存放都是二进制数据
redis在启动时就会从这个db文件中恢复数据
save命令要在redis-cli里执行

save

在redis.conf中配置save指令

以下参数都可以在redis.conf文件内设置

# 用来设定本地数据库名称，默认dump.rdb，通常设置为dump-端口号.rdb
dbfilename "dump-端口号.rdb"
# dir设置储存rdb文件的目录，默认./ (./代表当前目录)
dir ./
# 设置储存至本地数据库是否压缩数据，默认yes，推荐yes，如果设为no可以节省cpu的运行时间，文件储存会变大
rdbcompression yes
# 设置是否对RDB文件进行校验，默认yes，设为no可以节省性能10%，但是储存一定数据时具有损坏风险
rdbchecksum yes
# 后台储存出现错误，是否要停止保持操作，这只对bgsave指令有效
stop-writes-on-bgsave-error yes

RDB save指令的注意事项

在redis服务器中，指令是单线程一条一条执行，使用save指令会阻塞redis服务器，如果保持的数据过大，save指令会花费很长的时间，这样就会大大拉低服务器的性能，所以在线上环境中不推荐使用save指令，推荐使用bgsave指令来执行持久化

RDB bgsave指令

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

bgsave的原理

bgsave指令会在后台完成持久化操作，redis服务器会单独调用一个子线程去执行这个save指令，不会影响服务器本身

在配置文件中配置bgsave

bgsave的配置参数和save指令的参数基本相同，stop-writes-on-bgsave-error yes参数用来指定，如果后台储存出现错误，是否要停止保持操作，通常默认开启yes

# 用来设定本地数据库名称，默认dump.rdb，通常设置为dump-端口号.rdb
dbfilename dump-端口号.rdb
# dir设置储存rdb文件的目录，默认./ (./代表当前目录)
dir ./
# 设置储存至本地数据库是否压缩数据，默认yes，推荐yes，如果设为no可以节省cpu的运行时间，文件储存会变大
rdbcompression yes
# 设置是否对RDB文件进行校验，默认yes，设为no可以节省性能10%，但是储存一定数据时具有损坏风险
rdbchecksum yes
# 后台储存出现错误，是否要停止保持操作，这只对bgsave指令有效
stop-writes-on-bgsave-error yes

配置自动持久化

我们通常并不会通过手动指定来保存持久化数据，一般都是服务器自动执行，redis同样支持

配置自动化注意事项

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

AOF(append only file)持久化

概念

AOF持久化以日志的形式记录服务器所处理的每一个写、删除操作，查询操作不会记录，以文本的方式记录，可以打开文件看到详细的操作记录。
AOF持久化:以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程

AOF主要作用

AOF的主要作用是解决了数据持久化的实时性,目前已经是redis持久化的主流方式

配置AOF

1.在redis中AOF功能是通过配置文件redis.conf来开启的

# 是否开启AOF持久化功能，默认为不开启状态
appendonly yes|no

2.配置当前redis实例aof文件的名称

# 系统默认 appendonly.aof，为了好区分建议加当前实例的端口号
appendfilename “appendonly—端口号.aof”

3.配置AOF写数据策略

appendfsync always|everysec|no

策略名称	含义	优缺点
always（每次）	每次执行一个命令都同步至AOF文件中	数据零失误，性能较低，不建议使用
everysec（每秒）	每秒将缓冲区中的指令同步到AOF文件中	数据准确性较高，性能较高，建议使用，也是默认配置，即便系统宕机，也只会丢失一秒的数据
no（系统控制）	由操作系统控制每次同步到AOF文件的周期	整体过程不可控

4.以配置文件的方式启动redis，看到data文件内多了这么一个aof文件就表示aof已经启动了

AOF（优化）重写

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

AOF重写的作用

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

AOF重写的规则

AOF重写方式

1.手动重写，使用命令

bgrewriteaof

2.自动重写 通过配置配置（.conf）文件设置自动重写

# 自动重写的最小百分比
auto-aof-rewrite-percentage 100
# 自动重写aof的最小尺寸
auto-aof-rewrite-min-size 64mb

触发条件

1. aof_current_size>auto-aof-rewrite-min-size就会触发重写
2. (aof_current_size-aof_base_size)➗aof_base_size的百分比大于auto-aof-rewrite-percentage就会触发重写

可以通过info命令查看有关参数，例如：aof_current_size，aof_base_size

RDB与AOF之间的选择