1、Redis的持久化方式

1.1、redis为了防止数据丢失以及服务重启时能够恢复数据，Redis支持数据的持久化，主要分为两种方式，分别是RDB和AOF。

1.2、Redis 支持的持久化机制 有三种：

1、RDB（Redis DataBase）持久化

2、AOF（Append Only File）持久化

3、RDB-AOF 混合持久化

1.3、Redis 默认有 16 个数据库，分别是 DB0 ~ DB15。

2、RDB

RDB持久化是把当前进程数据生成快照保存到磁盘上的过程，由于是某一时刻的快照，那么快照中的值要早于或者等于内存中的值。

生成的rdb文件的名称以及存储位置由redis.conf中的dbfilename和dir两个参数控制，默认生成的rdb文件是dump.rdb。

2.1、触发方式

触发rdb持久化的方式有2种，分别是手动触发和自动触发。

手动触发

redis客户端执行save命令和bgsave命令都可以触发rdb持久化，但是两者还是有区别的。

1.使用save命令时是使用redis的主进程进行持久化，此时会阻塞redis服务，造成服务不可用直到持久化完成，线上环境不建议使用；

2.bgsave命令是fork一个子进程，使用子进程去进行持久化，主进程只有在fork子进程时会短暂阻塞，fork操作完成后就不再阻塞，主进程可以正常进行其他操作。

3.bgsave是针对save阻塞主进程所做的优化，后续所有的自动触发都是使用bgsave进行操作。

自动触发

在以下4种情况时会自动触发

1、redis.conf中配置save m n，即在m秒内有n次修改时，自动触发bgsave生成rdb文件；

2、主从复制时，从节点要从主节点进行全量复制时也会触发bgsave操作，生成当时的快照发送到从节点；

3、执行debug reload命令重新加载redis时也会触发bgsave操作；

4、默认情况下执行shutdown命令时，如果没有开启aof持久化，那么也会触发bgsave操作；

配置示例：

save 900 1

save 300 10

save 60 10000

配置分别表示：

900秒（15分钟）内有1个更改

300秒（5分钟）内有10个更改

60秒内有10000个更改

2.2、bgsave 命令的执行流程：

1、若父进程存在正在执行的子进程，直接返回

2、fork 操作（创建子进程） 执行过程中，父进程进入阻塞状态

3、fork 操作 完成后，父进程继续响应其他命令

4、创建 “.rdb” 文件，并存储 父进程内存中的数据

5、父进程 得到通知，以新的 “.rdb” 文件 替换旧的 “.rdb” 文件

2.3、bgsave 命令的原理：COW（Copy On Write）

在 Linux 操作系统中，可以通过 glibc库 中的 fork 函数 创建一个子进程，该进程与父进程完全相同，并且共享 父进程 的内存空间

当 父进程 或 子进程 需要修改内存中的数据时，会将对应的 page 进行复制，然后对副本进行修改

2.4、RDB 的优缺点：

优点

RDB文件是某个时间节点的快照，默认使用LZF算法进行压缩，压缩后的文件体积远远小于内存大小，适用于备份、全量复制等场景；

Redis加载RDB文件恢复数据要远远快于AOF方式；

缺点

RDB方式实时性不够，无法做到秒级的持久化；

每次调用bgsave都需要fork子进程，fork子进程属于重量级操作，频繁执行成本较高；

RDB文件是二进制的，没有可读性，AOF文件在了解其结构的情况下可以手动修改或者补全；

版本兼容RDB文件问题；

3、AOF

3.1、AOF介绍

aof方式持久化是使用文本协议将每次的写命令记录到aof文件中，经过文件重写后记录最终的数据生成命令，在redis启动时，通过执行aof文件中的命令恢复数据。

aof方式主要解决了数据实时性持久化的问题，aof方式对于兼顾数据安全性和性能非常有帮助。

说明：

目前 Redis 持久化 的主流方式（解决了数据持久化的实时性） 

以 独立日志 的方式，记录了每次写入的命令

生成一个 文本协议格式 的 文本文件（文件后缀为 “.aof”）

3.2AOD的启用

AOF 默认不开启，需要修改配置项来启动它：

appendonly yes # 启动 

aofappendfilename "appendonly.aof" # 设置文件名

注：AOF 保存的默认文件是 appendonly.aof

3.3、AOF可以配置三种刷盘策略：

appendfsync always：每次执行写命令都会刷盘，非常慢，也非常安全。

appendfsync everysec：每秒刷盘一次，兼顾性能和安全。

appendfsync no：将刷盘操作交给系统，很快，不安全。

推荐使用everysec，该策略下，最多会丢1秒的数据。

3.4、配置示例

打开配置文件，追加配置如下即可AOF配置。

vim /data/db/redis/6379/redis.conf

appendonly yes

appendfsync everysec

示例：
root@db01:/data/db/redis/6379# cat /data/db/redis/6379/redis.conf

daemonize yes   

port 6379

bind 172.21.209.40  127.0.0.1   

logfile /data/db/redis/6379/redis.log

dir /data/db/redis/6379/

dbfilename dump.rdb

requirepass 123456 

##RDB的配置

save 900 1

save 300 10

save 60 10000

##AOF的配置

appendonly yes

appendfsync everysec

4、两种方式对比

5、Redis混合持久化

重启 Redis 时，我们很少使用 RDB来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重

放，但是重放 AOF 日志性能相对 RDB来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很

长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。

通过如下配置可以开启混合持久化(必须先开启aof)：

# aof‐use‐rdb‐preamble yes

如果开启了混合持久化，AOF在重写时，不再是单纯将内存数据转换为RESP命令写入AOF文件，而是将重写这一刻之前的内存做RDB快照处理，并且将RDB快照内容和增量的AOF修改内存数据的命令存在一起，都写入新的AOF文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，覆盖原有的AOF文件，完成新旧两个AOF文件的替换。

于是在 Redis 重启的时候，可以先加载 RDB 的内容，然后再重放增量 AOF 日志就可以完全替代之前的AOF 全量文件重放，因此重启效率大幅得到提升。

5.1、混合持久化AOF文件结构如下：

6、Redis数据备份策略

1、写crontab定时调度脚本，每小时都copy一份rdb或aof的备份到一个目录中去，仅仅保留最近48

小时的备份。

2、每天都保留一份当日的数据备份到一个目录中去，可以保留最近1个月的备份。

3、每次copy备份的时候，都把太旧的备份给删了。

4、每天晚上将当前机器上的备份复制一份到其他机器上，以防机器损坏。