Redis的持久化策略RDB和AOF

介绍

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

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

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

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时，都会直接触发持久化。

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，需要在数据准确度还是数据恢复的速度上进行考虑。当然，如果有需要，都启用也是可以的。