Redis 持久化

Redis 有两种持久化方案

• RDB （Redis DataBase）
• AOF （Append Only File）。

一、RDB

RDB 是 Redis 默认的持久化方案。是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

1.1 RDB优缺点

优点：

1. 适合大规模的数据恢复。
2. 如果业务对数据完整性和一致性要求不高，RDB是很好的选择。

缺点：

1. 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2. 备份时占用内存，因为Redis 在备份时会独立创建一个子进程，将数据写入到一个临时文件（此时内存中的数据是原来的两倍哦），最后再将临时文件替换之前的备份文件。所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

1.2 RDB相关配置

打开 redis.conf 文件，找到 SNAPSHOTTING 对应内容

RDB核心规则配置
#save <seconds> <changes>
# save ""
save 900 1
save 300 10
save 60 10000
#指定本地数据库文件名
dbfilename dump.rdb
#指定本地数据库存放目录
dir ./
#默认开启数据压缩
rdbcompression yes

说明1：save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。
若不想用RDB方案，可以把 save "" 的注释打开，下面三个注释。

说明2：配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，但会导致数据库文件变的巨大。建议开启。

1.3 如何触发RDB快照

1. 在指定的时间间隔内，执行指定次数的写操作
2. 执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令
3. 执行flushall 命令，清空数据库所有数据
4. 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据。

1.4 如何通过RDB文件恢复数据

将dump.rdb 文件拷贝到redis的本地数据库存放目录下，重启redis服务即可。在实际开发中，一般会考虑到物理机硬盘损坏情况，选择备份dump.rdb 。

二、AOF

AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍。Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启后会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

2.1 AOF优缺点

优点：

​ 数据的完整性和一致性更高

缺点：

​ 1、因为AOF记录的内容多，文件会越来越大，数据恢复也会越来越慢。

​ 2、AOF每秒fsync一次指令硬盘，如果硬盘IO慢，会阻塞父进程；风险是会丢失1秒多的数据；在Rewrite过程中，主进程把指令存到mem-buffer中，最后写盘时会阻塞主进程

2.2 AOF相关配置

打开 redis.conf 文件，找到 APPEND ONLY MODE 对应内容

#aoy的开关，默认是no关闭状态
appendonly yes
#本地数据库文件名
appendfilename "appendonly.aof"

#指定更新日志条件
#appendfsync always
appendfsync everysec
#appendfsync no

#配置重写触发机制
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 1G

说明1：
always：同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差当数据完整性比较好（慢，安全）
everysec：出厂默认推荐，每秒异步记录一次（默认值）
no：不同步

说明2：当AOF文件大小是上次rewrite后大小的一倍且文件大于1G时触发。可根据实际情况设置大小。

2.3 如何触发AOF快照

根据配置文件触发，可以是每次执行触发，可以是每秒触发，可以不同步。

2.4 如何根据AOF文件恢复数据

正常情况下，将appendonly.aof 文件拷贝到redis配置的本地数据库存放目录下，重启redis服务即可。但在实际开发中，可能因为某些原因导致appendonly.aof 文件格式异常，从而导致数据还原失败，可以通过命令redis-check-aof --fix appendonly.aof 进行修复 。

2.5 AOF的重写机制

重写的原理：

Redis 会fork出一条新进程，读取内存中的数据，并重新写到一个临时文件中。AOF重写并不需要对原有AOF文件进行任何的读取，写入，分析等操作，这个功能是通过读取服务器当前的数据库状态来实现的。并没有读取旧文件。最后替换旧的aof文件

触发机制：

当AOF文件大小是上次rewrite后大小的一倍且文件大于1G时触发。这里的“一倍”和“1G” 可以通过配置文件修改。

三、如何选择RDB和AOF

对于我们应该选择RDB还是AOF，官方的建议是两个同时使用。并且生产环境中一般也是同时使用RDB和AOF，这样可以提供更可靠的持久化方案。当然如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。