Redis的持久化

2022-05-18 13:55:21

Redis的持久化取舍和选择

持久化的作用

什么是持久化

redis所有的数据都是保存在内存中，对数据的更新将异步的保存在磁盘中，如果数据没有持久到硬盘中，当redis服务器重启，redis数据将会丢失

RDB

什么是RDB

RDB持久化是把当前进程数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发。

RDB触发机制 -- 主要三种

save (同步)

save命令：阻塞当前Redis服务器，知道RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，先上环境不建议使用

127.0.0.1:6379> save
OK

文件策略：如存在老的 RDB文件，新老替换
时间复杂度： O(n)

bgsave (异步)

bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一段时间很短

文件策略：如存在老的 RDB文件，新老替换
时间复杂度： O(n)

自动触发（Redis默认RDB持久化方式）

 保存：RDB文件保存在dir配置指定的目录下，文件名通过dbfilename配置指定。可以通过执行config set dir {newDir} 和 config set dbfilename {newFileName}运行期动态执行，当下次运行时RDB文件会保存到新目录。
压缩：Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩后的文件远远小于内存大小，默认开启，可以通过参数config set rdbcompression {yes|no}动态修改。

校验：如果Redis加载损坏的RDB文件时拒绝启动，并打印如下日志：

Short read or OOM loading DB. Unrecoverable error , aborting now.
这时可以使用Redis提供的redis-check-dump工具检测RDB文件并获取对应的错误报告

127.0.0.1:6379> bgsave
Background saving started

RDB总结

RDB是Redis内存到硬盘的快照，用于持久化。
save 通常会阻Redis
bgsave 不会阻塞Redis，但会fork新经常
save 自动配置满足任意条件就会执行

优点

Redis加载RDB恢复数据远远快于AOF方式。
RDB是一个紧凑压缩的二进制文件，代表Redis在某一个时间点上的数据快照。非常适合用于备份，全量复制等场景。比如每6小时执行bgsave备份，并把RDB文件拷贝到远程机器或者文件系统中（如hdfs），用于灾难恢复。

缺点

耗时、耗性能，RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB笨笨，存在老版本Redis服务无法兼容新版RDB格式的问题。

如何恢复

自动恢复：自动读取dump.rdb文件恢复将备份文件移动到redis安装目录并启动服务即可。 CONFIG GET dir获取目录
注意：对dump.rdb文件进行备份执行cp命令
cp dump.rdb dumo_new.rdb

AOF

什么是AOF

AOF(append only file)持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式。

AOF 三种策略

always
everysec
no

操作系统决定的

3者对比

重写机制

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是吧Redis进程内的数据转化为写命令同步到新AOF文件的过程。

作用

减少硬盘占用量
加快恢复速度

重写的2种方式

bgrewriteaof

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

aof 重写配置

根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积，默认为64MB

auto-aof-rewrite-percentage:代表当前AOF文件空间（aof_current_size）和上一次重写后AOF文件空间（aof_base_size）的值

自动触发时机=aof_current_size>auto-aof-rewrite-min-size && (aof_current_size-aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage
其中aof_current_size和aof_base_size可以再info Persistence统计信息中查看。

AOF重写流程

配置

//开启aof
appendonly yes

//aof日志
appendfilename  "appendonly-${port}.aof"

//aof 持久化策略
appendsync eneeyec

//目录
dir /bigdiskpath

//重写的内容配置   
//增长率
auto-aof-rewrite-percentage 100

//尺寸
auto-aof-rewrite-min-size  64mb

恢复数据

1. 设置appendonly yes；
2. 将appendonly.aof放到dir参数指定的目录；
3. 启动Redis，Redis会自动加载appendonly.aof文件。

优缺点

AOF 的优点

使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写

缺点

对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积

RDB和AOF的选择

RDB 和 AOF比较

RDB 和 AOF ,我应该用哪一个？

一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性，你应该同时使用两种持久化功能，RDB
当作备份来处理，AOF主要用来恢复数据

个人博客：http://blog.yanxiaolong.cn/

码农公寓