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文件较大 | — | — |
所以，如何选择RDB和AOF，需要在数据准确度还是数据恢复的速度上进行考虑。当然，如果有需要，都启用也是可以的。
我是半月，祝你幸福！！！
