概述：

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

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

RDB

简介：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在?些毫秒级不能响应客户端请求

AOF

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

AOF持久化策略：

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

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

3. appendfsync no：从不同步

AOF重写机制：

aof采??件追加?式，?件会越来越?，为了避免出现此情况，redis新增了重写机制，当aof?件的??超过所设定的阈值时，redis就会启动aof?件的内容压缩，只保留可以恢复数据的最?指令集。当然我们也可以使?命令bgrewriteaof?动告诉redis进?aof?件的重写，这样可以有效减少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或者更?