什么叫持久化？
用一句话可以将持久化概括为：将数据（如内存中的对象）保存到可永久保存的存储设备中。持久化的主要应用是将内存中的对象存储在数据库中，或者存储在磁盘文件中、 XML 数据文件中等等。
同时，也可以从应用层和系统层这两个层面来理解持久化：
应用层：如果关闭( Close )你的应用然后重新启动则先前的数据依然存在。
系统层：如果关闭( Shutdown )你的系统（电脑）然后重新启动则先前的数据依然存在。
Redis 为什么要持久化？
Redis 中的数据类型都支持 push/pop、add/remove 及取交集并集和差集及更丰富的操作，而且这些操作都是原子性的。在此基础上，Redis 支持各种不同方式的排序。与 Memcached 一样，为了保证效率，数据都是缓存在内存中。当你重启系统或者关闭系统后，缓存在内存中的数据都会消失殆尽，再也找不回来了。所以，为了让数据能够长期保存，就要将 Redis 放在缓存中的数据做持久化存储。
Redis 怎么实现持久化？
在设计之初，Redis 就已经考虑到了这个问题。官方提供了多种不同级别的数据持久化的方式：
- RDB持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
- AOF持久化方式记录每次对服务器写的操作,当服务器重启的时候会重新执行这些命令来恢复原始的数据,AOF命令以redis协议追加保存每次写的操作到文件末尾.Redis还能对AOF文件进行后台重写,使得AOF文件的体积不至于过大。
- 如果你只希望你的数据在服务器运行的时候存在,你也可以不使用任何持久化方式。
- 你也可以同时开启两种持久化方式, 在这种情况下, 当redis重启的时候会优先载入AOF文件来恢复原始的数据,因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
RDB持久化
- RDB 是一个非常紧凑的文件,它保存了某个时间点的数据集，非常适用于数据集的备份。
- 比如你可以在每个小时保存一下过去 24 小时内的数据，同时每天保存过去 30 天的数据，这样即使出了问题你也可以根据需求恢复到不同版本的数据集。
- RDB 是一个紧凑的单一文件，很方便传送到另一个远端数据中心，非常适用于灾难恢复。
- RDB 在保存 RDB 文件时父进程唯一需要做的就是 Fork 出一个子进程，接下来的工作全部由子进程来做，父进程不需要再做其他 IO 操作，所以 RDB 持久化方式可以最大化 Redis 的性能。
- 与 AOF 相比，在恢复大的数据集的时候，RDB 方式会更快一些。
Redis RDB 是最简单的 Redis 持久性模式。当满足特定条件时，它将生成数据集的时间点快照，例如，如果先前的快照是在2分钟前创建的，并且现在已经至少有 100 次新写入，则将创建一个新的快照。此条件可以由用户配置 Redis 实例来控制，也可以在运行时修改而无需重新启动服务器。快照作为包含整个数据集的单个 .rdb 文件生成。
但我们知道，Redis 是一个 单线程 的程序，这意味着，我们不仅仅要响应用户的请求，还需要进行内存快照。而后者要求 Redis 必须进行 IO 操作，这会严重拖累服务器的性能。
还有一个重要的问题是，我们在 持久化的同时，内存数据结构 还可能在 变化，比如一个大型的 hash 字典正在持久化，结果一个请求过来把它删除了，可是这才刚持久化结束，咋办？
操作系统多进程 COW(Copy On Write) 机制 拯救了我们。Redis 在持久化时会调用glibc 的函数 fork 产生一个子进程，简单理解也就是基于当前进程 复制 了一个进程，主进程和子进程会共享内存里面的代码块和数据段。
所以 快照持久化 可以完全交给 子进程 来处理，父进程 则继续 处理客户端请求。子进程 做数据持久化，它 不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是 父进程 不一样，它必须持续服务客户端请求，然后对 内存数据结构进行不间断的修改。
这个时候就会使用操作系统的 COW 机制来进行 数据段页面 的分离。数据段是由很多操作系统的页面组合而成，当父进程对其中一个页面的数据进行修改时，会将被共享的页面复 制一份分离出来，然后 对这个复制的页面进行修改。这时 子进程 相应的页面是 没有变化的，还是进程产生时那一瞬间的数据。
子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化 叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。
触发机制
手动触发分别对应save和bgsave命令
save命令：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存 比较大的实例会造成长时间阻塞，线上环境不建议使用
bgsave命令：Redis进程执行fork操作创建子进程，RDB持久化过程由子 进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短
自动触发RDB的持久
- 使用save相关配置，如“save m n”。表示m秒内数据集存在n次修改 时，自动触发bgsave。
- 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点，更多细节见6.3节介绍的复制原理。
- 执行debug reload命令重新加载Redis时，也会自动触发save操作。
- 默认情况下执行shutdown命令时，如果没有开启AOF持久化功能则 自动执行bgsave。
RDB的缺点：
RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运 行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式 的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。
针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。
AOF持久化
-
使用 AOF 会让你的 Redis 更加耐久。
-
你可以使用不同的 Fsync 策略：无 Fsync、每秒 Fsync 、每次写的时候 Fsync 使用默认的每秒 Fsync 策略。
-
Redis 的性能依然很好( Fsync 是由后台线程进行处理的，主线程会尽力处理客户端请求)，一旦出现故障，你最多丢失 1 秒的数据。
-
AOF文件是一个只进行追加的日志文件，所以不需要写入 Seek，即使由于某些原因(磁盘空间已满，写的过程中宕机等等)未执行完整的写入命令，你也可使用 redis-check-aof 工具修复这些问题。
-
Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。
与RDB存储某个时刻的快照不同，AOF持久化方式会记录客户端对服务器的每一次写操作命令，并将这些写操作以Redis协议追加保存到以后缀为aof文件末尾，在Redis服务器重启时，会加载并运行aof文件的命令，以达到恢复数据的目的。
AOF持久化配置
在Redis的配置文件中存在三种同步方式，它们分别是：
appendfsync always #每次有数据修改发生时都会写入AOF文件。
appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。
appendfsync no #从不同步。高效但是数据不会被持久化。
AOF 重写
Redis AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新 AOF 文件的过程，重写之后的 AOF 文件会比旧的 AOF 文件占更小的体积，这是由以下几个原因导致的：
- 进程内已经超时的数据不再写入文件
- 旧的 AOF 文件含有无效命令，如 del key1、hdel key2、srem keys、set a111、set a222等。重写使用进程内数据直接生成，这样新的AOF文件只保 留最终数据的写入命令
- 多条写命令可以合并为一个，如：lpush list a、lpush list b、lpush list c可以转化为：lpush list a b c。为了防止单条命令过大造成客户端缓冲区溢 出，对于 list、set、hash、zset 等类型操作，以 64 个元素为界拆分为多条。
重写之后的 AOF 文件体积更小了，不但能够节约磁盘空间，更重要的是在 Redis 数据恢复时，更小体积的 AOF 文件加载时间更短。AOF 文件重写跟 RDB 持久化一样分为手动触发和自动触发，手动触发直接调用 bgrewriteaof 命令就好了，我们后面会详细聊一聊这个命令，自动触发就需要我们在 redis.conf 中修改以下几个配置
- auto-aof-rewrite-percentage：代表当前 AOF文件空间 （aof_current_size）和上一次重写后 AOF 文件空间（aof_base_size）的比值，默认是 100%，也就是一样大的时候
- auto-aof-rewrite-min-size：表示运行 AOF 重写时 AOF 文件最小体积，默认为 64MB，也就是说 AOF 文件最小为 64MB 才有可能触发重写
数据恢复
RDB-AOF混合持久化
redis4.0相对与3.X版本其中一个比较大的变化是4.0添加了新的混合持久化方式。前面已经详细介绍了AOF持久化以及RDB持久化，这里介绍的混合持久化就是同时结合RDB持久化以及AOF持久化混合写入AOF文件。这样做的好处是可以结合 rdb 和 aof 的优点, 快速加载同时避免丢失过多的数据，缺点是 aof 里面的 rdb 部分就是压缩格式不再是 aof 格式，可读性差。
开启混合持久化
4.0版本的混合持久化默认关闭的，通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，默认是禁用的，可通过config set修改。
混合持久化过程
了解了AOF持久化过程和RDB持久化过程以后，混合持久化过程就相对简单了。
混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后在将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据。
数据恢复
当我们开启了混合持久化时，启动redis依然优先加载aof文件，aof文件加载可能有两种情况如下：
- aof文件开头是rdb的格式, 先加载 rdb内容再加载剩余的 aof。
- aof文件开头不是rdb的格式，直接以aof格式加载整个文件。