前言：由于Redis的数据都存放在内存中，如果没有配置持久化，redis重启后数据就全丢失了，于是需要开启redis的持久化功能，将数据保存到磁盘上，当redis重启后，可以从磁盘中恢复数据。 Redis4.0之后，redis提供三种方式进行持久化，第一种是RDB持久化（原理是将Reids在内存中的数据库记录定时dump到磁盘上的RDB持久化），第二种是AOF（append only file）持久化（原理是将Reids的操作日志以追加的方式写入文件），第三种是混合持久化，本文将介绍这三种持久化方式。

1、RDB快照

这是Redis默认的持久化方式，RDB持久化是指在指定的时间间隔内将内存中的数据集快照写入磁盘，实际操作过程是fork一个子进程，先将数据集写入临时文件，写入成功后，再替换之前的文件，用二进制压缩存储。开启自动持久化后，数据会存储到名为 dump.rdb 的文件中。当 Redis 服务器重启时，检测到 dump.rdb 文件后，会自动加载进行数据恢复。
二、Redis持久化 - 图1

触发方式

手动触发：
save命令：会阻塞当前服务器，直到RDB完成为止，如果数据量大的话会造成长时间的阻塞，线上环境一般禁止使用；bgsave命令：就是background save，执行bgsave命令时Redis主进程会fork一个子进程来完成RDB的过程，完成后自动结束（操作系统的多进程Copy On Write机制，简称COW）。所以Redis主进程阻塞时间只有fork阶段的那一下。相对于save，阻塞时间很短。
自动触发：
配置redis.conf，触发规则，自动执行。

  1. # 当在规定的时间内，Redis发生了写操作的个数满足条件，会触发发生BGSAVE命令。
  2. # save <seconds> <changes>
  3. # 当用户设置了多个save的选项配置，只要其中任一条满足，Redis都会触发一次BGSAVE操作
  4. save 900 1 
  5. save 300 10 
  6. save 60 10000
  7. # 以上配置的含义：900秒之内至少一次写操作、300秒之内至少发生10次写操作、
  8. # 60秒之内发生至少10000次写操作，只要满足任一条件，均会触发bgsave

RDB的优缺点

优点

  • RDB文件小，非常适合定时备份，用于灾难恢复
  • Redis加载RDB文件的速度比AOF快很多，因为RDB文件中直接存储的时内存数据，而AOF文件中存储的是一条条命令，需要重演命令。

缺点

  • RDB无法做到实时持久化，若在两次bgsave间宕机，则会丢失区间（分钟级）的增量数据，不适用于实时性要求较高的场景
  • RDB的cow机制中，fork子进程属于重量级操作，并且会阻塞redis主进程
  • 存在老版本的Redis不兼容新版本RDB格式文件的问题

    2、AOF

    AOF日志是持续增量的备份，是基于写命令存储的可读的文本文件，先写入os cache，每隔一段时间 fsync到磁盘 。AOF日志会在持续运行中持续增大，由于Redis重启过程需要优先加载AOF日志进行指令重放以恢复数据，恢复时间会无比漫长。所以需要定期进行AOF重写，对AOF日志进行瘦身。目前AOF是Redis持久化的主流方式。
    二、Redis持久化 - 图2

    开启方式

    ```

    此选项为aof功能的开关，默认为“no”，可以通过“yes”来开启aof功能

    只有在“yes”下，aof重写/文件同步等特性才会生效

    appendonly yes

指定aof文件名称

appendfilename appendonly.aof

指定aof操作中文件同步策略，有三个合法值：always everysec no,默认为everysec

appendfsync everysec

在aof-rewrite期间，appendfsync是否暂缓文件同步，”no”表示“不暂缓”，“yes”表示“暂缓”，默认为“no”

no-appendfsync-on-rewrite no

aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb”

auto-aof-rewrite-min-size 64mb

相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比

每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)

aof文件增长到A*(1 + p)之后，触发下一次rewrite，每一次aof记录的添加，都会检测当前aof文件的尺寸。

auto-aof-rewrite-percentage 100

  1. 在上述配置文件中，可观察到Redis中提供了3中AOF记录同步选项：
  3. - always：每一条AOF记录都立即同步到文件，性能很低，但较为安全。
  4. - everysec：每秒同步一次，性能和安全都比较中庸的方式，也是redis推荐的方式。如果遇到物理服务器故障，可能导致最多1秒的AOF记录丢失。
  5. - no：Redis永不直接调用文件同步，而是让操作系统来决定何时同步磁盘。性能较好，但很不安全。
  6. <a name="yk9GG"></a>
  7. ### 重写机制
  8. AOF重写制分为：**手动触发**和**自动触发**<br />**手动触发** 直接调用bgrewriteaof命令<br />redis-cli -h ip -p port bgrewriteaof<br />**自动触发**<br />根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机

auto‐aof‐rewrite‐min‐size 64mb //aof文件至少要达到64M才会自动重写，文件太小恢复速度本来就 很快，重写的意义不大 auto‐aof‐rewrite‐percentage 100 //aof文件自上一次重写后文件大小增长了100%则再次触发重写 

  1. <a name="gnEl6"></a>
  2. ### AOF优缺点：
  3. **优点** AOF只是追加写日志文件，对服务器性能影响较小，速度比RDB要快，消耗的内存较少<br />**缺点**
  5. - AOF方式生成的日志文件太大，需要不断AOF重写，进行瘦身。
  6. - 即使经过AOF重写瘦身，由于文件是文本文件，文件体积较大（相比于RDB的二进制文件）。
  7. - AOF重演命令式的恢复数据，速度显然比RDB要慢。
  8. <a name="CpJ37"></a>
  9. ## 3、Redis4.0混合持久化
  11. - 仅使用RDB快照方式恢复数据，由于快照时间粒度较大，会丢失大量数据。
  12. - 仅使用AOF重放方式恢复数据，日志性能相对 rdb 来说要慢。在 Redis 实例很大的情况下，启动需要花费很长的时间。
  14. Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——**混合持久化**。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小。相当于：
  16. - 大量数据使用粗粒度（时间上）的rdb快照方式，性能高，恢复时间快。
  17. - 增量数据使用细粒度（时间上）的AOF日志方式，尽量保证数据的不丢失。
  19. 在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。<br />混合持久化配置（ 必须先开启aof ）：

aof-use-rdb-preamble yes # yes：开启，no：关闭 ```