说说redis持久化的两种机制：RDB和AOF

前言

redis有两种持久化机制，分别是AOF和RDB，现在就来说说两者的特点

RDB的原理

两个关键点：fork 和 write
fork：redis会单独创建（fork）一个和原进程一模一样的子进程来进行持久化。
write：这个进程会先将数据写入一个临时文件里，待持久化结束了再用这个文件替换上次持久化的文件

RDB什么时候触发呢

1：shutdown的时候，就是正常退出redis
2：redis.conf配置文件默认的快照配置，如下

save 900 1
save 300 10
save 60 10000

900 1 表示900秒内如果有1个key发生了变化，那么触发RDB。300 10以此类推。这个是可以自己改的
3：save和bgsave命令触发。
注意：
save是主进程进行持久化，所以其他任务会阻塞
bgsave是开启动个新进程进行持久化
4:flushall命令
这个命令过后redis就被清空了，所以没什么意义

RDB其他配置

dump.rdb是RDB机制持久化产生的文件，默认是这个名字，可以更改，配置如下

dbfilename dump.rdb

dump.rdb默认生成在执行redis-server命令时的位置。如果想要固定生成在一个位置，用绝对路径，配置如下：

dir  ./

AOF的原理

AOF是根据操作命令的历史日志进行持久化，redis开启时，会根据AOF持久化生成的文件里的内容，依次执行，恢复数据。AOF的出现是为了解决RDB出现的部分数据不一致的问题。

AOF的配置

需要在配置里将AOF开启，配置如下

appendonly yes

默认文件名appendonly.aof，当然也能进行更改，配置如下

appendfilename    "appendonly.aof"

触发机制

#appendfsync always
appendfsync everysec
#appendfsync no

always：每个数据一有变更就同步到磁盘。（慢，但是安全）
no：不同步到磁盘，由操作系统自行同步（性能最好）
everysec（默认）：每隔一秒同步到到磁盘
always和no都太极端，everysec是redis官方推荐的配置。在everysec的配置下，意味着最多丢失1秒的数据

AOF重写

aof持久化文件appendonly.aof会随着时间的推移越来越大，可能导致服务器磁盘都装不下。这时候需要进行重写。AOF重写就是对持久化文件进行瘦身。
重写原理：把多个命令合成一个。比如10次的i++，直接写成i=10。
aof重写需要fork一个子进程进行重写

AOF重写触发

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

auto-aof-rewrite-min-size：第一次触发重写的文件大小
默认64mb，表示当aof文件大于64mb触发重写。一般都要设置为5G，6G这样级别的大小

auto-aof-rewrite-percentag：文件大小增长率大于这个配置进行重写
默认100%。指的是第一次触发重写后，假如将64mb缩减为40mb，那么下次触发重写的大小是40+40=80mb。假如到了80mb再触发重写缩减为60mb，那么再下次触发的大小是60+60=120mb。
如果是80%，假设第一次重写64mb变为40mb，下一次是40+40*0.8 = 72mb时进行重写

结尾

如今的redis都是AOF和RDB同时开启。两种机制相辅相成。
RDB是直接将数据备份下来，所以相同数据量下文件大小比aof小，但是每次持久化都要开启一个和当前进程一摸一样的子进程来操作，开销比较大，不适合较高频率触发，因此它的数据一致性不能很好的保证，最多丢失两次持久化间隔时间的数据。
AOF呢，则是根据reids的历史操作命令进行持久化，通过配置appendfsync为everysec，使得aof每隔一秒进行磁盘持久化，在满足不错的一致性情况下（1秒内的数据丢失），还能有很好的性能，但是随着时间的推移，aof文件会越来越大，所以出现了aof的重写。aof的重写需要启动一个子进程执行，频繁的重写也会对redis性能造成极大的影响。所以重写的参数配置要合理，太小的话容易多次触发重写。
其实在redis的启动机制里，如果AOF开启且AOF文件存在的话，是默认优先加载AOF。只有AOF加载失败才去加载RDB文件。