Redis持久化机制

redis支持四种持久化方式，一是 Snapshotting（快照）也是默认方式（RDB）；二是Append-only file（缩写aof）的方式；三是虚拟内存方式；四是diskstore方式。

1.RDB(Redis DataBase)

RDB的实现方式为，在指定时间将当前时刻内存中的数据生成一个快照文件（.rdb文件，默认为dump.rdb），并将这个快照文件保存到磁盘上。这样，即使redis宕机了，下次重启时也可以通过读取这个快照文件来恢复数据。

rdb文件默认文件名为dump.rdb，是在配置文件中

 触发生成rdb快照文件的方式主要有五种：配置文件自动触发、执行save命令、执行bgsave命令、执行shutdown命令、执行flushall命令。

1.1 配置文件自动触发

redis默认的配置文件redis.conf中，有一个自动触发rdb持久化的配置：

# 时间策略
save 3600 1 -> 3600秒内有1个key被修改，则触发RDB
save 300 100 -> 300秒内有100个key被修改，则触发RDB
save 60 10000 -> 60秒内有10000个key被修改，则触发RDB

# 文件名称
dbfilename dump.rdb

# 文件保存路径
dir /home/work/app/redis/data/

# 如果持久化出错，主进程是否停止写入
stop-writes-on-bgsave-error yes

# 是否压缩
rdbcompression yes

# 导入时是否检查
rdbchecksum yes

 当满足其中任意一个save条件时，都会触发一次bgsave命令进行异步持久化。

1.2 执行save命令

save命令是一个同步操作，执行该命令后，RDB持久化是在主进程中进行的，这样会阻塞当前redis服务，直到RDB持久化完成后，客户端才能正常连接redis服务。

1.3 执行bgsave命令

bgsave命令是对save命令的一个优化，是一个异步操作。执行该命令后，redis主进程会通过fork操作创建一个子进程，RDB持久化是由子进程操作，完成后自动结束。这个过程中，主进程不阻塞，可以继续接收客户端的访问。因此，redis内部所有涉及RDB持久化的操作都是采用的bgsave方式，save命令基本已经废弃。

 1.4 执行shutdown命令

在客户端执行shutdown命令即可

1.5 执行flushall命令

flushall命令是清空redis内存中的数据，并且同时清空dump.rdb文件。所以这个命令就相当于删库跑路，此处只是说明该命令会触发rdb，实际使用中千万不要执行。

2.AOF 

        AOF是redis提供的另一种数据持久化方式，它会记录客户端对redis服务端的每一次写操作，并将这些写操作以redis协议追加保存到后缀为aof的文件末尾。在redis服务器重启时，会读取并加载aof文件，达到恢复数据的目的。

aof持久化方式redis是默认不开启的，我们可以通过配置文件开启aof持久化方式：

# 是否开启aof，默认是no
appendonly yes

# 文件名称
appendfilename "appendonly.aof"

# 同步方式
#appendfsync always       #每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
#appendfsync everysec     #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
#appendfsync no           #完全依赖os，性能最好,持久化没保证
appendfsync everysec

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
#auto-aof-rewrite-percentage 100：当文件的大小达到原先文件大小（上次重写后的文件大小，如果没有重写过，那就是redis服务启动时的文件大小）的两倍。
#auto-aof-rewrite-min-size 64mb：文件重写的最小文件大小，即当AOF文件低于64mb时，不会触发重写。只有这两个指标同时满足的时候才会发生重写。

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof时如果有错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

3.RDB和AOF对比

RDB的优点：

1. RDB文件非常紧凑，节省内存空间；
2. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快；
3. 适合全量备份、全量复制的场景，经常用于灾难恢复（对数据的完整性和一致性要求相对较低的场合）

RDB的缺点：

1. 服务器宕机时，可能会丢失部分数据；
2. 每次保存RDB的时候，Redis都要fork出一个子进程，这个过程是阻塞的，如果数据集巨大，那阻塞的时间就会很长。

AOF的优点：

1. 数据更加完整，丢失数据的可能性较低；
2. AOF日志文件可读，并且可以对AOF文件修复。

AOF的缺点：

1. AOF日志记录在长期运行中逐渐庞大，恢复起来非常耗时，需要定期对AOF日志进行瘦身处理；
2. 恢复备份速度比较慢。

参考：Redis持久化机制详解 - 知乎