Redis是基于内存的⾮关系型K-V数据库，既然它是基于内存的，如果Redis服务器挂了，数据就会丢失。为了避免数据丢失，Redis提供了持久化，即把数据保存到磁盘。

redis提供了两种持久化操作：RDB和AOF

简介：RDB（redis database）持久化，是指在指定的时间间隔内将内存中的数据集快照写⼊磁盘，也就是Snapshot快照，它是redis默认的持久化⽅式。执⾏完操作后，在指定⽬录下会⽣成⼀个dump.rdb⽂件，Redis重启的时候，通过加载dump.rdb⽂件来恢复数据。

触发机制：

a. save：save只管保存，其他不管，save是⼀个阻塞式命令。即当服务器接收了⼀条save命令之后就会开始拍摄快照，在此期间不会再去处理其他请求，其他请求会被挂起直到备份结束，应当避免使⽤

b. bgsave: redis会在后台异步进⾏快照操作，快照操作同时还可以响应客户端请求，与save命令区别就在于bgsave不会阻塞主进程处理的操作。redis会单独创建（fork）⼀个⼦进程进⾏持久化，先将数据写⼊到⼀个临时⽂件中，待持久化过程都结束了，再⽤这个临时⽂件替换上次持久化好的⽂件。

a. save m n : m秒内数据集存在n次修改时，⾃动触发bgsave

a. 如果需要进⾏⼤规模的恢复，且对于数据恢复的完整性不是⾮常敏感，那RDB⽅式要⽐AOF⽅式更加的⾼效

b. RDB很适合⽤于灾备，单⽂件很⽅便就能传输到远程的服务器上

c. 可以定期备份rdb⽂件，直接写个脚本就好了，很⽅便

a. 没办法做到实时持久化或秒级持久化

b. 最后⼀次持久化的数据可能丢失

c. rdb需要经常fork⼦进程来保存数据到硬盘上，当数据集⽐较⼤的时候，fork的过程是⾮常耗时的，可能导致redis在⼀些毫秒级不能响应客户端请求

简介：全称叫“append only file"，aof是以⽇志的形式来记录每个写操作，将redis执⾏过的所有写指令记录下来（读操作不记录），只许追加⽂件但是不可以改写⽂件，redis启动之初会读取⽂件重新构建数据，redis重启的话根据⽇志⽂件的内容将写指令从头到尾执⾏⼀次以完成数据的恢复。AOF⽅式持久化默认保存的是appendonly.aof⽂件。它主要解决数据持久化的实时性问题。默认是不开启的。

1. appendfsync always：Always：同步持久化，每次发⽣数据变更会⽴即记录到磁盘，性能较差但数据完整性⽐较好，always会严重影响服务器的性能

2. appendfsync everysec：Everysec：默认就是此⽅式，异步操作，每秒记录，如果⼀秒内宕机，这⼀秒数据有可能丢失

3. appendfsync no：从不同步

aof采⽤⽂件追加⽅式，⽂件会越来越⼤，为了避免出现此情况，redis新增了重写机制，当aof⽂件的⼤⼩超过所设定的阈值时，redis就会启动aof⽂件的内容压缩，只保留可以恢复数据的最⼩指令集。当然我们也可以使⽤命令bgrewriteaof⼿动告诉redis进⾏aof⽂件的重写，这样可以有效减少aof⽂件的体积

1.  redis会fork出⼀个⼦进程来对aof⽂件进⾏重写，原理跟快照持久化命令bgsave的⼯作原理类似，值得注意的是，进⾏aof⽂件重写时，如果原来的aof⽂件体积已经⾮常⼤，那么重写aof并删除旧aof⽂件的过程将会对redis的性能造成较⼤的影响

2.  auto-aof-rewrite-percentage：配置当aof⽂件需要⽐旧aof⽂件增⼤多少时才进⾏重写

3. auto-aof-rewrite-min-size：配置当aof⽂件需要达到多⼤体积时才进⾏重写

4. 只有上⾯2，3配置的条件都达到时，才会进⾏重写

1. 数据的⼀致性和完整性更⾼

2. 使⽤默认的持久化策略：每秒同步⼀次，redis最多只会丢失1秒的数据

3. aof⽂件的格式可读性较强，同时还可以检查aof⽂件中的错误并进⾏修复

对相同的数据集来说，aof⽂件的体积通常要⼤于rdb⽂件体积，恢复速度慢于rdb

1. redis允许同时存在rdb和aof两种持久化⽅式，但是重启时redis会优先加载aof⽂件

2. 如果在项⽬中只是将redis作为缓存服务器的话，我们其实可以不⽤进⾏持久化，因为缓存对数据的敏感性没那么强

3. aof持久化⽅式最多只会丢失⼀秒数据，但是这带来了很多额外的io操作，其次就是重写造成的阻塞不可避免，所以应该尽量减少aof重写的频率，建议将参数auto-aof-rewrite-min-size修改为5g或者更⼤