【Redis学习笔记】第六章 Redis持久化

---

---

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查看。也可通过配置文件修改。

4.4 各持久化策略下AOF重写流程

---

5、RDB与AOF的对比

• RDB与AOF的选择各有利弊
• 不能承受数分钟以内的数据丢失，对业务数据非常敏感，选用AOF
• 能承受数分钟以内的数据丢失，且追求大数据集的恢复速度，选用RDB
• 灾难恢复选用RDB
• 双保险策略，同时开启 RDB 和 AOF，重启后，Redis优先使用 AOF 来恢复数据，降低丢失数据的量