一、什么是redis的持久化
redis持久化的机制如下图
二、redis持久化的两种方式
方式一:RDB将当前数据快照到.rdb格式文件。
方式二:AOF将写操作追加到缓冲区,再将缓冲区的操作同步到磁盘。
三、两种持久化方式的对比
1)RDB不能实时持久化数据,如果redis服务器断电可能存在丢失数据的风险。而AOF方式持久化做到实时实时持久化数据。
2)加载RDB恢复数据远快于AOF方式。因为RDB是二进制数据,而AOF是日志的形式。
3)如果用高版本redis进行RDB持久化的文件用到低版本redis启动恢复会出现不兼容的问题。
四、RDB持久化(默认开启这种方式)
1)持久化分为
手动
和
自动
两种机制
自动机制:当redis启动的时候初始化一个定时函数,
每隔一段时间会执行一次bgsave,将内存中的数据dump到硬盘。
手动机制:可以使用save或者bgsave命令手动将内存中的数据dump到磁盘。
2)save和bgsave命令
save
命令
:阻塞当前Redis主线程
,直到RDB
持久化过程完成为止,若内存实例比较大会造成长时间阻塞,
线上环境不建议用它
。
bgsave命令
:redis
进程执行fork
操作创建子线程,由子线程完成持久化,阻塞时间很短(微秒级),是save指令
的优化版本,
在执行redis-cli shutdown
关闭redis
服务时,如果没有开启AOF
持久化,自动执行bgsave。如下是bgsave流程图

3)内存备份到磁盘
步骤1 设置备份路径:config set dir /usr/redis
步骤2 使用命令:bgsave将文件备份到/usr/redis
4)将磁盘中的rdb文件数据恢复到内存
dump.rdb文件
放到redis
安装目录与redis.conf
同级目录(/usr/redis
),重启redis
即可。
5)RDB持久化方式的优缺点
优点:
1
.压缩后的二进制文,适用于备份、全量复制,用于灾难恢复。
2
.加载RDB
恢复数据远快于AOF
方式。
缺点:
1
.无法做到实时持久化,每次都要创建子进程,频繁操作成本过高。
2
.保存后的二进制文件,存在老版本不兼容新版本rdb
文件的问题。
五、AOF持久化(默认关闭的)
1)AOF配置信息(redis.conf)
appendonly yes //
启用
aof
持久化方式,默认是关闭的。
# appendfsync always //
每收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用
appendfsync everysec //
每秒强制写入磁盘一次,性能和持久化方面做了折中,推荐
# appendfsync no //
完全依赖os
,性能最好,
持久化没保证(操作系统自身的同步)
no-appendfsync-on-rewrite yes //
正在导出
rdb
快照的过程中
,
要不要停止同步
aof
auto-aof-rewrite-percentage 100 //aof
文件大小比起上次重写时的大小
,
增长率
100%
时
,
重写
auto-aof-rewrite-min-size 64mb //aof
文件
,
至少超过
64M
时
,
重写
2)AOF持久化流程
1
.所有的写入命令(set hset)
会append
追加到aof_buf
缓冲区中
2
.AOF
缓冲区向硬盘做sync
同步
3
.随着AOF
文件越来越大,需定期对AOF
文件rewrite
重写,达到压缩
4
.当redis
服务重启,可load
加载AOF
文件进行恢复
AOF
持久化流程:命令写入(append),
文件同步(sync),
文件重写(rewrite),
重启加载(load)

3)如何将aof文件恢复到内存
1.设置appendonly设置为yes。
2.
appendonly.aof
放到
dir
参数指定的目录
。
3.启动Redis
,Redis
会自动加载appendonly.aof
文件。
六、Redis重启时加载RDB、aof文件的顺序
1
.当AOF
和RDB
文件同时存在时,优先加载AOF
2
.若关闭了AOF
,加载RDB
文件
3
.加载AOF/RDB
成功,redis
重启成功
4
.AOF/RDB
存在错误,redis
启动失败并打印错误信息