【面试】Redis持久化RDB和AOF(原理，配置以及两者优缺点)

一：持久化：

redis时内存型的nosql数据库，项目数据时非常重要的，所以数据安全必须考虑，而redis支持将数据持久化到磁盘。redis默认是有持久化的，当我们存储一些数据时，会出现一个dump.rdb文件，这个文件就是用来持久化，保证我们的数据不会丢失。
redis一共有两种持久化方法，一个时RDB，一个时AOF

二：RDB(Snapshotting)

原理：首先redis是一个单线程，主服务就是一个单线程，并不是所有都是单线程。主服务会创建一个子进程，会将自己的所有数据给子进程copy一份，然后主服务继续工作，对外进行读和写服务。
然后子进程就会将父进程所给的数据往硬盘上写，就上刚才说的dump.rdb。然后呢就会隔一段时间进行一次备份。
RDB会每个一段时间去更新一下redis的数据，会生成一个二进制文件，RDB会通过一个bgsave的命令，会fork出一个子进程，通过一个写实复制的方式，生成一个RDB文件。

fork可以理解成克隆，会将文件写入到工作目录中，写入成功后，会将之前的替换掉。
配置：打开redis.conf
A：在redis.conf中找到save 900 1，这个意思时在900s之后改了一个key，给你进行一次持久化，300 10 意思时在300s之后修改了10个，则进行一次持久化，这个根据实际情况来修改。
B：
意思时在持久化失败后，是否要进行写服务，我认为，持久化失败了还是别进行写服务了，比较稳妥，读服务可以继续。
C：
这个就是子进程所写的文件，可以根据要求取修改名字

RDB优点：

RDB非常适合备份，因为他是将整个数据进行持久化，所以会保证数据的完整性，如果出现的话，也可以将数据还原出来，RDB数据体量小，执行速度快，适合做数据版本控制，可以进行数据的恢复和移植。
RDB缺点：
如果发生系统崩溃，则会丢失最近一次rdb之后的数据，所以如果项目不能接受这样的数据丢失，还需要其他的安全手段。因为rdn设置在一段时间后进行一次持久化，如果出现故障，就会丢失这几分钟的数据
RDB触发方式：
bgsave(触发RDB)。 save也可以 服务正常关闭也可以触发RDB
两者区别：bgsave是子进程来做RDB，save是主进程来做RDB。如果说是手动进行RDB，则save比较合适

三：AOF

1：原理:
Redis将每一个写操作(执行成功),写入到一个aof文件，Redis重启时只要从头到尾执行一次aop文件，既可恢复数据，也可以将aop文件复制到别的服务器，做数据移植。
注意：在重启时，要恢复数据，如果RDB文件和AOF文件同时存在，则以AOF为准
2：配置(还是打开redis.conf文件)：
appendonly yes 启动AOP机制
appendfsync always 每次收到写命令就立即强制写入磁盘，保证完全的持久化，但产生极大的IO开销(不推荐使用)
appendfsync everysec 每秒钟强制写入磁盘一次，在性 能和持久化方面做了很好的折中(推荐使用)
appendfsync no 由操作系统决定何时同步，如果系统宕机则导致redis丢失不定数量数据
appendfilename “appendonly.aop” 设置aop文件名
3：AOF优点
AOF会进行实时的写操作，不管你是每秒钟执行一次还是手动执行，都会将数据写入磁盘，即使系统崩溃，也只会丢失一秒钟的数据，比RDB更适于做更实时的持久化。
4：AOF缺点
A：在一直进行写操作，AOF文件会不断增长(可能比快照文件大几倍)，在极端情况下，可能会对硬盘空间造成压力
B：Redis在重启时，需要重新执行一个可能非常大的AOF，时间会很长

AOF与RDB的区别
RDB持久化是在指定的时间内将数据写入磁盘，实际操作时主进程fork出一个子进程，让子进程将数据写入，写入成功后在替换点之前的文件。
AOF是一个简短的写指令，在每一秒进行一次写指令，单次的消耗远低于RDB，所以AOF更适合做实时的持久化，将新加入的数据写入文件。