目录
1、简介
2、RDB
2.1 简介
2.2 Fork
2.3 自动触发
2.2 手动触发
2.3 RDB持久化文件的备份
3、AOF
3.1 简介
3.2 AOF配置
3.3 AOF修复功能
3.4 AOF重写
4、混合持久化
5、总结
1、简介
Redis的非常快，很大一部分原因是因为Redis的数据存储在内存中，既然在内存中，那么当服务器宕机或者断电的时候，数据就会全部丢失了，所以Redis提供了两种机制来保证Redis数据不会因为故障而全部丢失，这种机制称为Redis的持久化机制。
Redis的持久化机制有两种：
RDB(Redis Data Base) 内存快照
AOF(Append Only File) 增量日志
**RDB(Redis DataBase) **指的是在指定的时间间隔内将内存中的数据集快照写入磁盘，RDB是内存快照（内存数据的二进制序列化形式）的方式持久化，每次都是从Redis中生成一个快照进行数据的全量备份。
优点：
存储紧凑，节省内存空间
恢复速度非常快
适合全量备份、全量复制的场景，经常用于灾难恢复（对数据的完整性和一致性要求相对较低的场合）
缺点：
容易丢失数据，容易丢失两次快照之间Redis服务器中变化的数据。
RDB通过fork子进程对内存快照进行全量备份，是一个重量级操作，频繁执行成本高。
fork子进程，虽然共享内存，但是如果备份时内存被修改，最大可能膨胀到2倍大小。
AOF(Append Only File)是把所有对内存进行修改的指令（写操作）以独立日志文件的方式进行记录，重启时通过执行AOF文件中的Redis命令来恢复数据。AOF能够解决数据持久化实时性问题，是现在Redis持久化机制中主流的持久化方案（后续会谈到4.0以后的混合持久化）。
优点：
数据的备份更加完整，丢失数据的概率更低，适合对数据完整性要求高的场景
日志文件可读，AOF可操作性更强，可通过操作日志文件进行修复
缺点：
AOF日志记录在长期运行中逐渐庞大，恢复起来非常耗时，需要定期对AOF日志进行瘦身处理（后续详述）
恢复备份速度比较慢
同步写操作频繁会带来性能压力
官网地址
2、RDB
2.1 简介
RDB持久化方案进行备份时，Redis会单独fork一个子进程来进行持久化，会将数据写入一个临时文件中，持久化完成后替换旧的RDB文件。在整个持久化过程中，主进程（为客户端提供服务的进程）不参与IO操作，这样能确保Redis服务的高性能，RDB持久化机制适合对数据完整性要求不高但追求高效恢复的使用场景。
下面展示RDB持久化流程：
2.2 Fork
上面说到了RDB持久化过程中，主进程会fork一个子进程来负责RDB的备份，这里简单介绍一下fork
Linux操作系统中的程序，fork会产生一个和父进程完全相同的子进程。子进程与父进程所有的数据均一致，但是子进程是一个全新的进程，与原进程是父子进程关系
出于效率考虑，Linux操作系统中使用COW(Copy On Write)写时复制机制，fork子进程一般情况下与父进程共同使用一段物理内存，只有在进程空间中的内存发生修改时，内存空间才会复制一份出来。
在Redis中，RDB持久化就是充分的利用了这项技术，Redis在持久化时调用glibc函数fork一个子进程，全权负责持久化工作，这样父进程仍然能继续给客户端提供服务。fork的子进程初始时与父进程（Redis的主进程）共享同一块内存；当持久化过程中，客户端的请求对内存中的数据进行修改，此时就会通过COW机制对数据段页面进行分离，也就是复制一块内存出来给主进程去修改。
RDB触发的规则分为两大类，分别是手动触发和自动触发：
自动触发：
配置触发规则
shutdown触发
flushall触发
手动触发：
save
bgsave
2.3 自动触发
以下介绍Redis的RDB持久化机制中的自动触发机制中的配置触发规则来触发RDB，涉及到RDB规则的配置、文件存储路径配置、文件名配置、文件压缩配置、文件完整性校验配置。
2.3.1 配置规则触发
在Redis安装目录下的redis.conf配置文件中搜索 /snapshot即可快速定位，配置文件默认注释了下面三行数据，通过配置规则来触发RDB的持久化，需要开启或者根据自己的需求按照规则来配置
2.3.3 flushall触发
首先这里一定要特别注意，flushall是删库跑路，它是清空dump.rdb文件，千万千万不要看了博主的文章，跑到公司备份的时候顺手来个flushall，然后到时候来问候我……，这个flushall是为了清空Redis数据的同时清空dump.rdb文件，要不然重启Redis的时候，数据又会恢复到上一次备份的时候的数据，与flushall的执行指令含义就冲突了。
为了证明这个文件不会保留数据，我特地特地的写个脚本测试一下：
编写一个批量插入的脚本文件
2.2 手动触发
手动触发RDB持久化的方式可以使用save命令和bgsave命令，这两个命令的区别如下。
save：执行save指令，阻塞Redis的其他操作，会导致Redis无法响应客户端请求，不建议使用。
bgsave：执行bgsave指令，Redis后台异步进行快照的保存操作，此时Redis仍然能响应客户端的请求。
2.3 RDB持久化文件的备份
在实际的生产环境中，我们一般不会使用主节点Master来进行持久化备份，我们会通过在Redis的多个从服务器上进行RDB持久化备份，这样是为了对Redis数据的多次备份，防止出现网络分区或者部分节点宕机甚至是硬件损坏的情况发生。
作为运维或者架构师，李子捌觉得应该要定时定期的通过脚本对Redis持久化文件进行转移备份，这样双重保险，更加可靠，万一遇到突发情况，也是多一手解决方案。
3、AOF
3.1 简介
Redis配置文件中开启，AOF持久化方案进行备份时，客户端所有请求的写命令都会被追加到AOF缓冲区中，缓冲区中的数据会根据Redis配置文件中配置的同步策略来同步到磁盘上的AOF文件中，同时当AOF的文件达到重写策略配置的阈值时，Redis会对AOF日志文件进行重写，给AOF日志文件瘦身。Redis服务重启的时候，通过加载AOF日志文件来恢复数据。
3.2.2 同步频率配置
AOF日志是以文件的形式存在的，当程序对AOF日志文件进行写操作时，实际上将内容写到了内核为文件描述符分配的一个内存缓冲区中，随后内核会异步的将缓冲区中的数据刷新到磁盘中。如果缓冲区中的数据没来得及刷回磁盘时，服务器宕机了，这些数据就会丢失。
因此Redis通过调用Linux操作系统的glibc提供的fsync(int fid)来将指定文件的内容强制从内核缓冲区刷回磁盘，以此来保证缓冲区中的数据不会丢失。不过这是一个IO操作，相比Redis的性能来说它是非常慢的，所以不能频繁的执行。
Redis配置文件中有三种刷新缓冲区的配置：
appendfsync always
每次Redis写操作，都写入AOF日志，这种配置理论上Linux操作系统扛不住，因为Redis的并发远远超过了Linux操作系统提供的最大刷新频率，就算Redis写操作比较少的情况，这种配置也是非常耗性能的，因为涉及到IO操作，所以这个配置基本上不会用
appendfsync everysec
每秒刷新一次缓冲区中的数据到AOF文件，这个Redis配置文件中默认的策略，兼容了性能和数据完整性的折中方案，这种配置，理论上丢失的数据在一秒钟左右
appendfsync no
Redis进程不会主动的去刷新缓冲区中的数据到AOF文件中，而是直接交给操作系统去判断，这种操作也是不推荐的，丢失数据的可能性非常大。
3.4 AOF重写
前面提到AOF的缺点时，说过AOF属于日志追加的形式来存储Redis的写指令，这会导致大量冗余的指令存储，从而使得AOF日志文件非常庞大，比如同一个key被写了10000次，最后却被删除了，这种情况不仅占内存，也会导致恢复的时候非常缓慢，因此Redis提供重写机制来解决这个问题。Redis的AOF持久化机制执行重写后，保存的只是恢复数据的最小指令集，我们如果想手动触发可以使用如下指令：
Redis4.0后的重写使用的是RDB快照和AOF指令拼接的方式，在AOF文件的头部是RDB快照的二进制形式的数据，尾部是快照产生后发生的写入操作的指令。
由于重写AOF文件时，会对Redis的性能带来一定的影响，因此也不能随便的进行自动重写，Redis提供两个配置用于自动进行AOF重写的指标，只有这两个指标同时满足的时候才会发生重写：
auto-aof-rewrite-percentage 100：指的是当文件的内存达到原先内存的两倍
auto-aof-rewrite-min-size 64mb：指的是文件重写的最小内存大小
AOF重写流程如下：
bgrewriteaof触发重写，判断是否存在bgsave或者bgrewriteaof正在执行，存在则等待其执行结束再执行
主进程fork子进程，防止主进程阻塞无法提供服务，类似RDB
子进程遍历Redis内存快照中数据写入临时AOF文件，同时会将新的写指令写入aof_buf和aof_rewrite_buf两个重写缓冲区，前者是为了写会旧的AOF文件，后者是为了后续刷新到临时AOF文件中，防止快照内存遍历时新的写入操作丢失
子进程结束临时AOF文件写入后，通知主进程
主进程会将上面3中的aof_rewirte_buf缓冲区中的数据写入到子进程生成的临时AOF文件中
主进程使用临时AOF文件替换旧AOF文件，完成整个重写过程
5、总结
最后来总结这两者，到底用哪个更好呢？
推荐是两者均开启
如果对数据不敏感，可以选单独用RDB
不建议单独用AOF，因为可能会出现Bug
如果只是做纯内存缓存，可以都不用
Redis官网是这么介绍的：
看不懂就看下Redis中文网的介绍：
Redis官网关于持久化的介绍
https://redis.io/topics/persistence
Redis中文网关于持久化的介绍
http://redis.cn/topics/persistence.html
