你不知道的redis三-Redis的持久化机制

一、持久化

我们前两章已经讲了，redis是内存型的数据库，他之所以快是因为数据存储在内存。那么数据存储在内存会有什么问题呢？当然就是当服务重启或者服务器宕机内存数据就被清除，我们就无法访问之前存储的数据了。那么怎么解决这个问题呢？当然就是使用持久化技术

持久化（Persistence），即把数据（如内存中的对象）保存到可永久保存的存储设备中（如磁盘）。持久化是将程序数据在持久状态和瞬时状态间转换的机制。比如JDBC就是一种持久化机制。文件IO也是一种持久化机制。

redis也是一个支持持久化的内存数据库,也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化，持久化可以避免因进程退出而造成数据丢失；

redis支持两种持久化方式，RDB和AOF

二、RDB持久化方式

RDB持久化把当前进程数据生成快照（.rdb）文件保存到硬盘的过程，有手动触发和自动触发

2.1 手动触发

手动触发有save和bgsave两命令

save命令：阻塞当前Redis，直到RDB持久化过程完成为止，若内存实例比较大会造成长时间阻塞，线上环境不建议用它

bgsave命令：redis进程执行fork操作创建子进程，由子线程完成持久化，阻塞时间很短（微秒级），是save的优化,在执行redis-cli shutdown关闭redis服务时，如果没有开启AOF持久化，自动执行bgsave;

bgsave流程如下：

2.2 RDB持久化命令

命令：config set dir /usr/local //设置rdb文件保存路径

备份：bgsave //将dump.rdb保存到usr/local下

恢复：将dump.rdb放到redis安装目录与redis.conf同级目录，重启redis即可

2.3 恢复和异常流程演示

1，查看启动目录，没有dump文件

2、set值

3、执行shutdown命令关掉服务，查看目录，已经生成对应的dump文件。

4、重启redis服务，发现数据还存在

5、执行shutdown命令关掉服务，并把dump文件删除

6、启动redis在进行查看，发现存储的数据已经不存在了。

2.4 RDB持久化的优缺点

优点：

压缩后的二进制文，适用于备份、全量复制，用于灾难恢复

加载RDB恢复数据远快于AOF方式

缺点：

无法做到实时持久化，每次都要创建子进程，频繁操作成本过高

三、AOF持久化

针对RDB不适合实时持久化，redis提供了AOF持久化方式来解决

开启方式就是在redis.conf设置：appendonly yes (默认不开启，为no)

默认文件名：appendfilename "appendonly.aof"

3.1 AOF持久化原理

所有的写入命令(set hset)会append追加到aof_buf缓冲区中

AOF缓冲区向硬盘做sync同步

随着AOF文件越来越大，需定期对AOF文件rewrite重写，达到压缩

当redis服务重启，可load加载AOF文件进行恢复

3.2 AOF持久化配置

配置信息含义

appendonly yes启用aof持久化方式

appendfsync always每收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用

appendfsync everysec每秒强制写入磁盘一次，性能和持久化方面做了折中，推荐

no-appendfsync-on-rewrite yes正在导出rdb快照的过程中,要不要停止同步aof

auto-aof-rewrite-percentage 100aof文件大小比起上次重写时的大小,增长率100%时,重写

auto-aof-rewrite-min-size 64mbaof文件,至少超过64M时,重写

3.3 AOF持久化恢复

1. 设置appendonly yes；

2. 将appendonly.aof放到dir参数指定的目录；

3. 启动Redis，Redis会自动加载appendonly.aof文件。

四、Redis持久化加载机制顺序

如果同时都开启了AOF和RDB 两种持久化方式，那么加载顺序及流程如下

当 AOF 和 RDB 文件同时存在时，优先加载 AOF

若关闭了 AOF，加载 RDB 文件

加载 AOF/RDB 成功，redis 重启成功

AOF/RDB 存在错误，redis 启动失败并打印错误信息

转自：https://blog.csdn.net/b379685397/article/details/108130809?utm_medium=distribute.pc_feed.none-task-blog-personrec_tag-4.nonecase&depth_1-utm_source=distribute.pc_feed.none-task-blog-personrec_tag-4.nonecase&request_id=5f439919cea070620e93ef00