1.持久化

一提到持久化，我们就会第一时间联想到M有SQL的事务，MySQL事务有四个比较核心的特征：原子性（把多个操作打包成一个整体），一致性（事务执行之前和之后，数据都不能离谱），持久性（事务中做出的修改都会保存在硬盘上）隔离性（事务并发执行，涉及一系列的问题）

Redis是一个内存数据库，数据存储在内存中，内存中的数据是不持久化的，要想做到持久化，就需要让Redis把数据存储到硬盘上。Redis决定内存中存储数据（快！），硬盘中也存数据（持久化）。当要插入到一个新的数据时，就需要把这个数据写入到内存和硬盘上，当查询这个数据的时候，直接从内存中读取，硬盘中的数据知识在Redis重启的时候，用来恢复内存中的数据，但代价是消耗更多的空间，毕竟一份数据存两遍。

持久化可以简单理解为数据存储硬盘上，Redis支持RDB和AOF两种持久化机制，持久化功能有效地避免因进程退出造成数据丢失的问题，当下次重启时候利用之前持久化生成的文件即可实现数据的恢复。

2.RDB

RDB持久化就是把当前进程中的数据生成快照保存到硬盘的过程，触发RDB持久化过程分为手动触发和自动触发，Redis会定期给内存中当前存储这些数据，拍成一个快照，生成一个文件存储在硬盘中，后续Redis一旦重启，内存数据就没了，可以根据快照文件把内存中的数据恢复回来。

2.1触发机制

2.1.1手动触发

程序员通过Redis客户端，执行特殊的命令，来触发生成快照。手动触发分别对应的save和bgsave命令：

save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例造成长时间阻塞，基本不采用。

bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责（不会影响Redis服务器处理其他客户端的请求和命令），完成后自动结束。阻塞只发生在fork阶段，一般时间很短。Redis内存所有设计RDB的操作都采用类似的bgsave的方式。

2.1.2自动触发

除了自动触发外，Redis运行自动触发（Redis配置文件中）RDB持久化，这个触发机制才是比较有价值的

1.使用save配置，如save m n 表示m秒内数据集发生n次修改，自动触发RDB持久化

2.从节点进行全量复制的时候，主节点自动进行RDB持久化，随后将RDB文件发送给从节点

3.执行shutdown命令关闭Redis时，执行RDB持久化。

2.2流程说明

bgsave是主流的RDB持久化方式

 bgsave命令的运行流程：

1.执行bgsave，判断当前是否已经存在其他正在工作的子进程，如果有其他进程正在bgsave，此时就直接把当前的bgsave返回

2.如果没有其他子进程，就通过fork这个样的系统调度一个子进程来，fork过程中会阻塞，可以通过info status 命令查看lastest_fork_usec选项，可以获取最近一次fork操作的耗时，单位为微秒。

3.父进程完成fork后，bgsave命令返回Background saving started信息并不再阻塞父进程，生成快照的过程中父进程继续接受客户端的请求，继续提供服务。

4.子进程创建RDB文件，根据父进程内存生产临时快照文件，完成后对原有文件进行原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的时间，对应info统计rdb_last_save_time选项

5.子进程发送信号给父进程表示完成，父进程更新统计信息。

fork是linux系统提供的一个创建子进程的api（系统调用），fork创建子进程简单粗暴，直接把当前（父进程）复制一份，作为子进程。一旦复制完成，父子进程就是两个独立的进程，格子执行各自的任务。

fork复制的过程中，会复制pcb，虚拟地址空间（内存中的数据），文件描述符表。本来Redis Server中若干变量保存了一些键值对，随着这样的fork进行，子进程的这个内存空间也会存在和父进程中一摸一样的数据。接下来安排子进程去执行持久化操作，也就相当于父进程本地这里的内存数据给持久化了。父进程打开一个文件，fork之后，子进程同样可以使用该文件，也就导致了子进程持久化写入的那个文件和父进程本来要写的文件是同一个。

这个时候就会有人问了，如果当前Redis服务器中存储的数据特别多，内存消耗特别大，进行上述复制操作，是否有很大的性能开销？

此处的性能开销其实挺小的。fork在进行内存拷贝时，不是简单无脑将所有元素复制一份，而是通过写时拷贝的机制完成的。如果父进程和子进程的内存数据完全相同，此时不会触发真正的拷贝动作（父子使用一份内存），但是这两个进程的内存空间应该是各自独立完成的。一旦某一个进程对内存数据做了修改，就会触发真正的物理内存上的数据拷贝。在进行bgsave这个场景中绝大部分的内存是不需要修改的，因此子进程的写时拷贝并不会触发很多次，也保证了整体拷贝的时间时可控的，高效的。

2.3RDB文件的处理

2.3.1保存

保存：RDB文件保存在dir配置的指定目录（默认/var/lib/redis/）下，文件名通过dbfilename配置（默认dump.rdb）指定。可以通过执行config  set  dir {newDir} 和 config  set  dbfilename {newFilename}运行期间动态执行，当下次运行的RDB文件会保存到新的目录。当生成的RDB镜像操作的时候，此时就会生成快照数据，先保存在一个临时的文件中，当快照生成完毕之后，再删除之前的rdb文件，把新生成的临时rdb文件改为dump.rdb。自始至终，rdb文件始终有一个

2.3.2 压缩

压缩：Redis默认采用LZF算法对生成的RDB文件做压缩处理，压缩处理后的文件远远小于呢哦村大小，默认开启，可以通过参数config  set  rdbcompression  {yes | no} 动态修改。虽然压缩 RDB文件会消耗CPU，但可以大幅度减低文件的体积，方便保存到硬盘或通过网络发送到从节点，因此建议开启。

2.3.3 校验

校验：如果Redis启动时加载到损坏的RDB文件会拒绝启动，这是可以使用Redis 提供的redis-check-dump工具检测RDB文件并获取对应的错误报告

其实是一个符号链接，在启动redis的时候就是进行检查rdb文件的完整性

 2.4 RDB文件优缺点

优点：

RDB是紧凑压缩的二进制文件，代表Redis在某个时间点上生成的数据快照。非常适用于备份，全量复制等场景，把RDB文件复制到远程机器或者是文件系统中用于灾备。Redis加载RDB恢复数据非常快（二进制）

缺点：

RDB方式持久化数据无法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork创建子进程，俗语重量级操作，频繁执行成本高。RDB文件使用特定的二进制格式保存。Redis版本严谨过程中有多个RDB版本，兼容性可能有风险。