Redis持久化——RDB和AOF原理和官方推荐

Redis的数据存储在内存中，基于内存计算，同时也支持持久化，将数据落盘到磁盘或文件中持久化存储，Redis提供了两种不同形式的持久化方式：RDB（Redis DataBase）和AOF（Append Of File）。

一、 RDB持久化

1. 关于fork

2. RDB的保存策略

3. RDB优点和缺点

二、AOF持久化

1. 保存策略

2. 优点和缺点

三、Redis持久化官方推荐

---

一、 RDB持久化

每隔一段时间，将内存中的数据集快照写入磁盘，也就是Snapshot快照，恢复时将快照文件直接读取到内存中；

Redis会单独创建（fork）一个子进程来进行持久化，先将数据写入到临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个持久化过程中，主进程不进行任何IO操作，如果需要进行大规模数据的恢复，并且对于数据恢复的完整性不是非常敏感，使用RDB方式会更加高效。

1. 关于fork

在linux中，fork（）会产生一个和主进行完全相同的子进程，通过写时复制技术，一般情况父进程和子进程会共用同一段物理内存，主进程负责写，子进程负责复制主进程的内容。

2. RDB的保存策略

redis保存的文件默认为dump.rdb，保存策略写在redis.conf的第202-204行

save 900 1         #900秒内若至少有1个key的值变化，则保存
save 300 10        #300秒内若至少有10个key的值变化，则保存
save 60 10000      #60秒内若至少有10000个key的值变化，则保存

3. RDB优点和缺点

（1）优点

间隔一段时间保存一次快照，节省磁盘空间，并且恢复速度快

（2）缺点

数据庞大时，写时复制技术需要拷贝的数据很多，比较消耗性能

间隔一段时间做一次备份，如果Redis意外宕机，就会丢失最后一次快照后的所有修改，也就是说宕机前的最后一次快照后的操作丢失了

 

二、AOF持久化

与RDB持久化以快照方式存储不同，AOF持久化以日志形式记录每个更新操作，将Redis执行过的所有写指令记录下来（读指令不记录），只许追加文件但不改写文件，在Redis启动之初会读取该文件重新构建数据，也就是说，AOF持久化的恢复数据方式是根据日志文件的内容将写指令从前到后执行一次。

AOF默认不开启，需要手动在redis.conf文件中配置，文件名称默认为appendonly.aof。

593行 appendonly no

594行 # The name of the append only file (default: "appendonly.aof")

595行 appendfilename "appendonly.aof"

1. 保存策略

redis.conf文件的622行：

# appendfsync always
appendfsync everysec
# appendfsync no

（1）appendfsync always：每次产生一条新的写指令都保存，效率最低，最安全；

（2）appendfsync everysec：每秒钟执行一次写指令保存，如果在未保存当前秒内操作时redis宕机，那么会导致当前1秒钟的数据丢失；

（3）appendfsync no：从不保存，将数据交给操作系统来处理，速度最快，但是也最不安全；

一般推荐选择的（默认）是appendfsync everysec，这种fsync策略可以兼顾速度和安全性。

2. 优点和缺点

（1）优点

备份时间间隔更短，丢失数据概率更低

（2）缺点

比RDB持久占用更多的磁盘空间，

由于数据量大，恢复备份速度更慢，

每次读写都同步的话，有一定的性能压力，

AOF持久化存在个别BUG，造成数据不能恢复。

 

三、Redis持久化官方推荐

1. 当RDB和AOF同时开启，系统默认读取AOF的数据恢复，

2. 官方推荐两个都用，

3. 如果对数据不敏感，可以单独选用RDB，

4. 不建议单独使用AOF，因为可能出现BUG，

5. 如果只是做纯内存缓存，不需要持久化，那么两个都不用