Redis持久化

1.RDB

在指定的时间间隔内将内存中的数据集快照写入到磁盘中去，它恢复时是将快照文件直接读到内存中里。
Redis会单独创建（fork)一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

Fork的作用是复制一个与当前进程一样的进程,内存中的数据也被复制了一份。
bgsave和save的区别：bgsave是后台异步进行的。
缺点：
最后一次持久化后的数据可能丢失。（因为save提交中间有一个时间，如果在那个时间内服务器宕机，就会丢失最后一次set进来的值）
两倍的资源占用（复制一个与当前进程一样的进程,内存中的数据也被复制了一份）

2.AOF(只记录写操作)

以日志的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来(读操作不记录)， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行，一次以完成数据的恢复工作

rewrite是什么？

​ AOF采用文件追加方式，文件会越来越大，为避免出现此种情况，新增了重写机制, 当AOF文件的大小超过所设定的阈值（64M）时，Redis就会启动AOF文件的内容压缩， 只保留可以恢复数据的最小指令集。

缺点：
​ 比起RDB占用更多的磁盘空间。
​ 恢复备份速度慢。
AOF默认不开启 持久化文件默认叫appendonly.aof
思考：如果RDB和AOF都开启，Redis会听谁的？
​ 系统默认取AOF的数据（数据不会存在丢失）

总结：
官方推荐两个都启用。
如果对数据不敏感，可以选单独用RDB。
不建议单独用 AOF，因为可能会出现Bug。
如果只是做纯内存缓存，可以都不用。