RDB

rdb持久化原理：

会涉及到操作系统底层的fork调用，详情查看：https://zhangxueliang.blog.csdn.net/article/details/104076571

会fork出一个子进程用于持久化。

当redis主进程发生数据修改的时候，会触发内核级别的写时复制操作，写数据到持久化文件是子进程来完成的，数据的增删改是在父进程中进行的，所以redis的持久化是fork+copy on write来实现的。

比如8点fork出一个子进程用于持久化操作，此时子进程拷贝的是8点时的数据，父子进程的数据修改，彼此都不可见。假如10点redis数据发生了修改，此时会由内核的写时复制机制触发数据复制操作，将引用指向新的数据，此时子进程的引用还是指向旧数据。写时复制不是为了数据同步，而是数据隔离。

fork出来的子进程会一直等到数据持久化做完后才销毁。每次持久化开始时都会fork出一个子进程。每次拍快照（持久化）都是当前时间点的全量数据覆盖之前的快照数据，如果快照采用增量更新的方式的话，需要在内存中判断哪些数据有更新哪些没更新，反而消耗CPU资源。

拷贝引用的成本比拷贝数据的成本低很多，因为一个引用的大小是4个字节，但引用指向的数据可能是一个数组几百个字节。

redis RDB持久化配置方式：

如果想关闭持久化，只需在配置文件redis.conf中配置：

save ""

redis.conf配置文件中配置持久化文件相关信息：

RDB的弊端：

①不支持拉链。由于只有一个dump.rdb持久化文件，所以会丢失前些天的数据，需要手工将dump文件拷贝出来。比如：我需要某一天的dump文件，如果不手工干涉的话，也许已经被覆盖了。

②丢失数据相对多一些。时点与时点之间的窗口数据容易丢失，比如8点得到一个dump.rdb，8：15要落一个rdb，结果挂机了。

RDB的优势：

类似于Java中的序列化，恢复数据的速度较快。想象一下，传输一个json数据然后解析成对象load到内存快还是直接传输一个二进制字节数组直接就怼到了内存快？用大腿想都知道是后者啦！

正是由于RDB的弊端，才有了AOF：Append Only File 的持久化机制。

AOF

将redis的写操作记录到文件中。类似于MySQL中的redo log和binlog一样。这样的话，丢失数据就会少啦。

在redis中，RDB和AOF可以同时开启，但是AOF优先，只会使用AOF做重启后的数据恢复。

aof执行日志文件中的命令，速度相对rdb要慢。但丢失数据相对rdb少。

aof天然的弊端：

①日志体量无限变大；

②恢复慢。

优点如果能保住，日志还是可以用的，需要设计一个方案让日志，AOF足够小。

4.0以前通过日志重写来实现：

①删除抵销的命令

②合并重复的命令

4.0以后也是通过日志重写来实现，只不过进行了优化：

①将老的数据RDB到aof文件中，存储的是二进制格式的日志数据。

②将增量的以redis指令的方式append到aof日志文件中。

AOF是一个混合体，利用了RDB的快和日志的全量。

redis 4.0 以后，AOF中包含RDB全量快照数据，增加记录新的写操作。

开启AOF

IO流中为什么要flush一下才能将数据写到磁盘，因为磁盘IO操作都是由操作系统内核来进行的，数据先是下入到内存的buffer中，flush就是将数据从buffer中刷到硬盘。redis中也是如此：

always：每次发生数据变更，立即持久化到硬盘

ererysec：每秒持久化一次，也就是每秒调一次flush将buffer数据刷到硬盘

no：等待OS自己将数据刷到硬盘，buffer一满OS就会刷到硬盘。

效率对比：always < everysec < no

no-appendfsync-on-rewrite默认是no：可能会发生丢数据的情况。但不会与自己的子进程争抢IO操作权。