Redis持久化

                                               Redis之持久化

 

什么是持久化 ？

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

 

为什么要进行持久化？

防止数据的意外丢失，确保数据安全性

 

持久化过程保存什么

RDB  将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据

AOF 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程

 

RDB

RDB启动方式

save 手动执行一次保存操作

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

 

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

 

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

 

save second changes 自动执行

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

参数 

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

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

 

注意： save配置要根据实际业务情况进行设置，频度过高或过低都会出现性能问题，结果可能是灾难性的

            save配置中对于second与changes设置通常具有互补对应关系，尽量不要设置成包含性关系

            save配置启动后执行的是bgsave操作

 

RDB三种启动方式对比

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

RDB优点

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

RDB缺点

• RDB无论是指令还是利用配置，无法做到实时持久化，据有较大的可能性
• bgsave指令每次运行都要执行fork操作创建子进程,要牺牲一些性能
• Redis的众多版本中未进行RDBA文件格式统一，有可能出现各个版本服务器之间数据格式无法兼容的现象

AOF

AOF概念

AOF持久化：以独立日志的方式记录每一次写命令，重启是再将执行AOF文件中命令已达到恢复数据的目的。与RDB相比可简单描述为记录数据为记录数据的产生过程。

AOF写数据的三种策略

• always(每次)
  • 每次写入操作均同步到AOF文件中，数据零误差，性能较低
• everysec(每秒)
  • 每秒将缓冲区指令同步到AOF文件中，数据准确性较高，性能较高在系统突然宕机的情况下只会失去一秒的数据
• no(系统控制)
  • 有系统控制每次同步到AOF文件的周期整体过程不可控

AOF功能开启

配置： appendonly  yes | no

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

配置：appendfsync  always | everysec | no

作用：AOF写数据的策略

 

AOF的重写

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

AOF重写的作用

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

AOF重写规则

• 进程已超时的数据不再写入文件
• 忽略无效指令，重写时使用进程内数据直接生成，这样的AOF文件只保留最终数据的写入命令
• 对同一数据的多条写入命令合并为一条

AOF的重写方式

• bgrewriteaof 手动重写
• 自动重写
  • auto-aof-rewrite-min-size size
  • auto-aof-rewrite-percentage percentage

RDB 与 AOF对比

持久化方式	RBD	AOF
占用储存空间	小	大
存储速度	慢	快
恢复速度	快	慢
数据安全性	会丢失数据	依据策略觉得
资源消耗	高/重量级	低/轻量级
启动优先级	低	高