redis之持久化

1）RDB持久化：

每隔一段时间，将内存中的数据集写到磁盘

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

保存策略：

save 900 1    900 秒内如果至少有 1 个 key 的值变化，则保存

save 300   10   300 秒内如果至少有 10 个 key 的值变化，则保存

save 60 10000  60 秒内如果至10000 个 key 的值变化，则保存

 

2）AOF :  以日志形式记录每个更新（(总结、改）操作

Redis重新启动时读取这个文件，重新执行新建、修改数据的命令恢复数据。

保存策略：

（1）appendfsync always：每次产生一条新的修改数据的命令都执行保存操作；效率低，但是安全！

（2）appendfsync everysec：每秒执行一次保存操作。如果在未保存当前秒内操作时发生了断电，仍然会导致一部分数据丢失（即1秒钟的数据）。

（3）appendfsync no：从不保存，将数据交给操作系统来处理。更快，也更不安全的选择。

推荐（并且也是默认）的措施为每秒 fsync 一次， 这种 fsync 策略可以兼顾速度和安全性。

缺点：

1  比起RDB占用更多的磁盘空间

2 恢复备份速度要慢

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

4 存在个别Bug，造成恢复不能

选择策略：

可读的日志文本，通过操作AOF

官方推荐：

如果对数据不敏感，可以选单独用RDB；不建议单独用AOF，因为可能出现Bug;如果只是做纯内存缓存，可以都不用