Redis的持久化策略RDB和AOF

一、介绍

众所周知，redis是一个内存数据库，是一个经典的NOSQL类型的数据库。

我们常常拿redis来当成缓存，这得益于它存储数据的位置在内存中，这样在进行取数时，不用再进行磁盘IO，速度也会大大增加。

但是，也正是它存储在内存中，服务器若是断点、宕机，内存中的数据岂不是没有了。所以，redis还有它自己的持久化策略，将自己内存中的数据保存一份在磁盘中，以备不时之需。

二、持久化策略

1）RDB（默认）

rdb持久化策略，每隔一段时间将内存中的数据保存下来。等下次redis启动，就会自动加载这个文件的数据到内存中，进行恢复。

时间间隔、文件名都是可以设置的，修改redis.conf

################################ SNAPSHOTTING  ################################
# 当900秒内至少有1个键值对发生变动，触发持久化
save 900 1
# 当300秒内至少有10个键值对发生变动，触发持久化
save 300 10
# 当60秒内至少有10000个键值对发生变动，触发持久化
save 60 10000

# 转储数据库的文件名
dbfilename dump.rdb

# 持久化文件的目录
dir ./

此外，执行flushall命令清空数据库时，以及执行shutdown命令等手段退出Redis时，都会直接触发持久化。

2）AOF

AOF全称为Append Only File，指的是当我们执行每一条redis命令时（查询不会记录），都会追加到AOF文件的末尾。等下次redis启动时，redis会重新执行AOF文件中的命令，用来恢复数据。

在我们执行一条redis命令时，这条命令会先保存在一个叫做oscache的缓存，进而再保存至AOF文件当中。

由于AOF不是默认的持久化方式，我们需要在配置文件中打开它

# 打开AOF，可以和RDB一起使用
appendonly no

# 这是AOF追加命令的三种策略，触发一个叫做fsync的指令追加命令
# appendfsync always
appendfsync everysec
# appendfsync no

# 重写机制
# 当AOF文件大于64mb，并且比上一次重写的文件体积大了至少一倍，就会AOF重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

追加命令的三种策略
- always：每次有新的修改数据的命令，就会将缓冲区内的命令同步追加到AOF文件，十分安全，但是效率低
- everysec：默认每秒将缓冲区内的命令同步追加到AOF文件，但是无法做到实时持久化，还是会可能丢失一秒的数据
- no：交给操作系统来决定什么时候去同步追加数据
重写机制当命令一直持续不断的追加到AOF文件当中，文件会变得越来越大。所以就有了一个重写机制，它能将当前的AOF文件中的命令进行优化，重新恢复到最小指令集文件，这样文件的大小就会变小，在redis重启后，也能快速的恢复数据。

三、最后

RDB和AOF的优缺点

对比说明	RDB	AOF
数据的准确度、安全性由于`RDB`有一定的时间间隔，在服务器宕机时，数据恢复没有那么准确而`AOF`可以做到异步的命令追加，可以带来相当高的数据准确性	×	√
数据恢复如果数据量比较大，`RDB`的优势会比较明显，可以快速的进行恢复 `AOF`由于需要执行命令集，在数据恢复的速度方面会比较慢	√	×
文件大小 `RDB`文件小，`AOF`文件较大	—	—