Redis学习（十三）Redis持久化

什么是持久化

利用永久性的存储介质（例如硬盘）进行存储，在需要时将存储介质中的数据取出进行恢复

 

持久化的方式

• 保存数据集的形式（snapshot 快照） RDB
• 保存命令集的形式（log 日志） AOF

 

RDB

什么是RDB？

在指定的时间间隔内生成数据集的时间点快照

 

RDB的优点

1. 每次备份存储的是当前时间点的一个二进制压缩文件
2. 非常适用于灾难恢复，并且可以将RDB文件传送到别的数据中心备份
3. 恢复大数据集时比AOF速度更快

 

RDB的缺点

1. RDB备份时间长，无法做到实时性（服务器一旦宕机，一定会丢失数据，丢失的数据是上一次RDB时间点到宕机时的数据）
2. fork函数会创建子进程进行RDB工作，会影响服务器性能

 

启动RDB的三种方式

1. save指令
2. bgsave指令
3. 配置（工作原理与bgsave指令相同，位于redis.conf）

save seconds changes // seconds秒内完成changes次更改，就进行bgsave，如果seconds秒内没有达到changes次修改，则进入下一个计时周期

 

save的工作原理

Redis是单线程的，Redis服务器会依次处理每个指令，当执行save指令时，Redis线程会进入阻塞状态，save后的指令长时间处于阻塞状态，直到RDB工作完成

 

​​

 

 

bgsave的工作原理

客户端发送bgsave指令，Redis服务器会调用fork函数创建子进程，后台执行RDB操作，当子进程完成后，向服务器返回完成消息

 

三种启动方式的对比

方式	save指令	bgsave指令	配置
读写	同步	异步	异步
阻塞客户端指令	是	否	否
额外消耗内存	否	是	是
启动新进程	否	是	是
定时保存	否	否	是
根据次数保存	否	否	是

 

RDB的特殊启动方式

• 全量复制
• 服务器运行中重启

// 执行命令
debug reload

• 关闭服务器指定保存数据

// 执行命令
shutdown save

 

AOF（主流方式）

什么是AOF？

将Redis服务器执行的命令保存到缓冲区，达到某个存储策略时将缓存区所有命令保存到AOF文件中

 

AOF的优点

1. 根据不同的AOF策略，增强Redis的持久性（AOF的默认策略时一秒钟保存一次缓冲区命令，即使宕机，最多只会丢失1秒钟的数据）
2. AOF文件变得很大时，Redis会自动的对后台AOF进行重写，降低存储量
3. AOF的文件内容非常容易读懂

 

AOF的缺点

1. AOF的文件大小会越来越大
2. AOF速度慢于RDB

 

AOF实现的方式

配置文件（Redis.conf）

// 开启AOF持久化功能
appendonly yes|no                     // 是否开启AOF持久化功能
 
// 配置AOF策略
appendfsync always                    // 将每次执行的写入操作同步到AOF文件中
 
appendfsync everysec                  // 每1秒操作同步到AOF文件中
 
appendfsync no                        // 由系统控制AOF的同步周期，过程不可控
 
// AOF和RDB的持久化文件会放在同一个文件夹下
dir
 
// AOF文件名
appendfilename "appendonly.aof"

 

三种AOF存储策略的区别

方式	always	everysec	no
同步周期	每次执行的写入操作	每秒执行的写入操作	不可控
误差	没有误差	可能会有一秒误差	不可控
性能	较低	较高	不可控

 

AOF重写

1. 已经过时的数据不写入AOF文件
2. 新AOF文件只保留数据的最终写入指令
3. 多条数据写入指令改为一条

 

AOF重写实现方式

• 手动重写（指令）

// 手动重写
bgrewriteaof            // 后台重写aof

• 自动重写（配置）

// 自动重写
auto-aof-rewrite-min-size size size            // 默认32MB或64MB，当aof文件大小达到size就会开始aof重写
 
auto-aof-rewrite-percentage percentage         // 达到基础大小的百分比就会开始aof重写
 
 
// 触发相关比对参数
aof_current_size                               // 当前aof文件大小
 
aof_base_size                                  // 基础aof文件大小

 

bgrewriteof指令的工作原理

1. 客户端向服务器发送bgrewriteof指令
2. 服务器接收指令，调用fork函数创建新进程，并返回Background append only file rewriting started
3. 新进程重写AOF文件
4. 新进程返回AOF成功完成的消息

如果AOF文件出错了怎么办？

服务器可能在程序正在对AOF文件进行写入时停机，造成了AOF文件出错，那么redis在重启时会拒绝载入这个AOF文件来保证数据的一致性不受到损坏

 

解决AOF文件出错的方式：

• 为现有的AOF文件创建一个备份
• 使用redis-check-aof程序，对AOF文件进行修复

redis-check-aof --fix

• （可选）使用diff -u对比修复后的AOF文件和原始AOF文件的备份
• 重启redis服务端

 

RDB如何切换到AOF

1. 为最新的dump.rdb文件创建一个备份，并且将备份放在一个安全的地方
2. 执行以下两条命令

//  Redis会阻塞直到初始AOF文件创建完成为止，并且开启AOF
CONFIG SET appendonly yes

//  关闭RDB功能（可选）
CONFIG SET save ""

 

RDB与AOF的区别

持久化方式	RDB	AOF
占用存储空间	小（记录数据，可压缩）	大（记录操作，可重写）
存储数据	慢	快
恢复速度	快	慢
数据安全性	会丢失数据	依据决策决定
资源消耗	高、重量级	低、轻量级
启动优先级	低	高

 

RDB和AOF的取舍

1. 要求数据精确性，使用AOF
2. 数据阶段性有效，使用RDB
3. 可以AOF、RDB配合使用