Redis持久化

持久化简介

持久化概念：利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化。

为什么要持久化：防止数据的意外丢失，确保数据安全性。

RDB

RDB启动方式——save命令

save

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

数据保存在dump.rdb里

删除这个文件

再执行save操作，发现又生成了这个文件

RDB相关配置

改redis-6379.conf配置文件

重新启动服务

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

RDB启动方式 —— bgsave指令

bgsave

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

RDB启动方式 ——save配置

• 配置

save second changes

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

• 参数

  second：监控时间范围
  changes：监控key的变化量

在conf文件中配置

更改redis-6379.conf配置信息

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

RDB三种启动方式对比

方式	save指令	bgsave指令
读写	同步	异步
阻塞客户端指令	是	否
额外内存消耗	否	是
启动新进程	否	是

AOF

简介

AOF概念

• AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单描述为改记录数据为记录数据产生的过程。

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

AOF写数据三种策略

• always(每次）（不建议使用）
  每次写入操作均同步到AOF文件中，数据零误差，性能较低
• everysec（每秒）（建议使用）
  每秒将缓冲区中的指令同步到AOF文件中，数据准确性较高，性能较高
  在系统突然宕机的情况下丢失1秒内的数据
• no（系统控制）
  由操作系统控制每次同步到AOF文件的周期，整体过程不可控

AOF功能开启

• 配置

appendonly yes|no

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

• 配置

//AOF写数据策略
appendfsync always|everysec|no

更改redis-6379.conf的配置信息，先用always

重新启动服务

改成每秒一存

AOF相关配置

appendfilename filename

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

重新启动服务

dir

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

AOF重写概念与命令执行

AOF重写

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

AOF重写作用

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

AOF重写规则

AOF重写方式

• 手动重写

bgrewriteaof

• 自动重写

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage

手动重写

测试

AOF自动重写方式

• 自动重写触发条件设置

auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percent

RDB与AOF区别