redis持久化方案

一、什么是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启动失败并打印错误信息