redis学习（五）——redis的持久化rdb和aof_rdb文件存储过程

持久化

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

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

持久化过程保存的是什么？有两种

• 1. 将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据。在redis中这种文件的保存形式为二进制，在redis中称之为RDB
• 2. 将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。在redis中只保存写的命令，对读的命令不保存，在redis中称之为AOF

RDB

rdb文件，将数据（快照）保存在该rdb文件中，做到持久化。文件名与位置可在redis.conf配置文件中修改。产生

RDB启动方式：

• save命令：每执行一次就会进行一次保存操作，但save指令的执行会阻塞当前Redis服务器，直到RDB过程完成为止，有可能长时间造成阻塞。，不推荐使用（线上基本不用）（数据量过大，单线程执行方式造成效率过低启动时）如何处理，使用bgsave
• bgsave：手动执行后台保存操作，但不是立即执行，调用fork函数生成子进程，执行save操作。bgsave命令是针对save阻塞问题做的优化，Redis内部所有涉及到RDB操作都采用bgsave方式，save命令可以放弃
• save seconds changes：配置文件中的，满足限定时间范围内key的变化数量达到指定数量即进行持久化

三种方式的对比（save配置一bgsave来操作）

还有几种特殊的rdb启动方式，关闭服务器时，服务器运行过程中重启，全量复制

RDB中的相关配置

• dbfilename dump.rdb
  　　说明：设置本地数据库文件名，默认为dump.rdb
  　　经验:通常设置为dump-端口号.rdb
• dir
  　　说明：设置rdb文件的存储位置
  　　经验：通常设置成存储空间较大的目录中，目录名称为data
• rdbcompression yes
  　　说明：设置存储本地数据库时是否压缩数据，默认为yes，采用LZF压缩
  　　 经验：通常默认为开启状态，如果设置为no，可以节省CPU运行时间，但会使存储文件变大（巨大）
• rdbchecksum yes
  　　说明：设置成是否进行rdb文件格式校验，该校验过程在写文件和读文件过程均进行
  　　经验：通常设置为开启状态，若设置成no，可以节约读写进程约10%时间消耗，但是存储有一定的数据损坏风险。
• stop-writes-on-bgsave-err yes:
  　　说明：后台存储过程如果出现错误现象，是否停止保存操作
  　　 经验：通常默认为开启状态。
  

RDB的优缺点

优点：

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

缺点：

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

AOF

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

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

配置文件中这里配置aof是否开启和aof默认文件名

AOF写数据的三种策略：

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

AOF重写

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

作用：

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

AOF重写规则：

• 进程内已超时的数据不再写入文件
• 忽略无效指令，重写时使用进程内数据直接生成，这样AOF文件只保留最终数据的写入命令
• 对同一数据的多条写命令合并为一条指令，为防止数据量过大造成客户端缓冲区溢出，对list，set，hash，zset等类型，每条指令最多写入64个元素

AOF重写方式
手动重写：

bgrewriteaof

自动重写：

• 自动重写触发条件参数设置：

• 自动重写触发对比参数（运行info Persistence获取）

• 自动重写触发条件：
  

AOF工作流程



重写流程:

RDB和AOF的区别

RDB和AOF的选择

• 对数据非常敏感，建议使用AOF持久化方案

1. AOF持久化策略使用everysecond，每秒钟fsync一次。该策略redis仍可以保持很好的处理性能，并当问题出现时，最多丢失0-1秒的数据
2. 注意：由于AOF文件存储体积较大，且恢复速度慢

• 数据呈现阶段有效性，建议使用RDB持久化方案

1. 数据可以良好的做到阶段内无丢失（该阶段是开发者或运维人员手工维护的），且恢复速度较快，阶段内数据恢复采用RDB方案
2. 注意：利用RDB实现紧凑的数据持久化会是Redis性能降低

• 综合对比

1. RDB和AOF的选择实际上是在一种权衡，有利有弊
2. 如果不能承受数分钟以内的数据丢失，对业务数据非常敏感，建议使用AOF反正选择RDB
3. 灾难恢复使用RDB
4. 双保险策略，但性能上会损失