3. redis的持久化

fork

时点错误意思就是在一个时间内如果对所有数据进行拷贝，在还没来得及拷贝的数据发生修改时，数据和开始拷贝的那个时间点不一致。
使用管道，只要用了管道就会创建子进程，子进程可以看到父进程的数据，但不能修改父进程的数据，所以不会有时点错误。

copy on write

比如父进程的redis里的虚拟内存定义了一个a变量，它的地址是3，但它其实指向了物理内存的8，存的值是x，所以可以通过a把x这个值取出来。
子进程的虚拟内存里的a和父进程的a指向的是同一个物理内存地址
问题： 当任意进程有一个变量的话，另一个进程无法知道这个变量的值是否修改，是看不到。
所以有个copy on write，因为当出现这种问题的时候，父进程如果想要修改数据，不可能把所有数据都给修改，只是哪个变量的值发生改变就去修改哪个，比如子进程的a的值，本来是x，现在修改成w，w在物理内存的下标9的位置，那么子进程的a直接指向w的内存地址。

RDB

RDB是快照方式的持久化机制，所以要实现时点数据。
实现方式一个save命令，一个是bgsave命令，save在命令行中可以实现前台阻塞，bgsave就是后端的非阻塞方式，bgsave就会触发fork，创建子进程。
一般使用save时候是非常明确的时候，比如：关机维护
使用save时候还支持通过配置文件的编写出的规则，用的是save标识，但是触发的是bgsave。

都知道RDB是以全量拷贝数据的方式，比如8点时候redis中又abcd 4个数据，等到9点时候又要进行RDB全量拷贝数据，新增了的数据ef，那就会把abcdef 这些数据都给拷贝一遍，为什么要这样？
试问一下，难道之前的abcd 数据就一定不会被修改吗？不能保证吧？所以把最新的数据重新拷贝一份。

RDB的弊端

不支持拉链，只有一个dump.rdb文件，表示备份的数据文件
丢失数据的话会丢失很多，如果在下一次执行RDB的时候宕机了，这个时点内的数据都没了

AOF

因为RDB持久化方式的缺点，所以有了AOF的持久化方式，追加记录数据的写操作

AOF的优点就是丢失数据少，可以同时开启RDB和AOF的，不过都开启的话只会用AOF的持久化文件恢复，因为AOF相对来说数据丢失的少。在redis4.0版本后，AOF包含了RDB的全量数据，增加的新写入数据的操作。
AOF弊端： 体量会一直无限变大。
解决问题：通过日志让AOF文件尽量变小。
在4.0版本以前，删除抵消的命令，合并重复的命令，得到最终的一个文件。
4.0版本以后，AOF是一个混合体，将老的数据RDB到aof文件中（利用了RDB的快），将增量的以指令的方式Append到AOF，数据还能保存完整。