前言
Redis是一种K-V数据库，它的数据也可以进行持久化操作。因为redis的数据都保存在内存中，如果不进行及时的持久化，可能就会因为重启导致数据的丢失。这时候就需要对redis进行持久化操作，将数据保存在磁盘上。
redis提供了两种持久化方式，分别是AOF和RDB。下面分别对这里持久化方式进行解析。
1.RDB
RDB是将redis 的数据生成快照保存在磁盘上。
RDB有多种实现方式，分别如下：
- 执行save或bgsave命令。save命令会阻塞redis，此时不会响应客户端发送的请求直到RDB文件执行完成，所以一般不推荐使用。bgsave会创建子进程，由子进程完成数据快照，不会阻塞父进程。
- 根据配置文件的save m n规则进行快照。
- 主从复制时，从库全量复制同步主库数据，此时主库会执行bgsave命令进行快照；
- 客户端执行数据库清空命令FLUSHALL时候，触发快照；
- 客户端执行shutdown关闭redis时，触发快照；
bgsave命令的工作流程如下：
- 执行bgsave命令，redis父进程判断当前是否存在子进程如AOF\RDB子进程，如果存在说明正在备份，直接返回。
- 父进程进行fork创建子进程，此时redis父线程被阻塞。
- 子进程创建完成，bgsave返回“* Background saving started by pid xxx”信息，并不再阻塞父进程，可以继续响应其他命令。
- 子进程进程创建RDB文件，根据内存生成临时快照文件，完成后对原有文件进行原子替换。
- 进程发送信号给父进程表示完成，父进程更新统计信息。
save m n规则
save m n规则表示每隔m秒，redis中有n个键改变则自动触发bgsave，在redis.conf文件中可以进行配置，并且可以组合使用。
RDB持久化配置：
save m n#配置快照(rdb)促发规则，格式：save #save 900 1 900秒内至少有1个key被改变则做一次快照#save 300 10 300秒内至少有300个key被改变则做一次快照#save 60 10000 60秒内至少有10000个key被改变则做一次快照#关闭该规则使用svae “” dbfilename dump.rdb#rdb持久化存储数据库文件名，默认为dump.rdbstop-write-on-bgsave-error yes #yes代表当使用bgsave命令持久化出错时候停止写RDB快照文件,no表明忽略错误继续写文件。rdbchecksum yes#在写入文件和读取文件时是否开启rdb文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。dir "/etc/redis"#数据文件存放目录，rdb快照文件和aof文件都会存放至该目录，请确保有写权限rdbcompression yes#是否开启RDB文件压缩，该功能可以节约磁盘空间
优点
- RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。这种文件非常适合用于进行备份：比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
- RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心，或者亚马逊 S3 中。
- RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
- RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快
缺点
- 如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。因此你可能会至少 5 分钟才保存一次 RDB 文件。在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。
- 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。在数据集比较庞大时， fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端；如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。
2. AOF
redis还提供了AOF(Append Only File)，将每次的命令追加到磁盘文件中。当服务器出现故障时，从文件中读取丢失数据时间点之后的命令，重新执行一遍命令达到恢复的目的。
redis默认是关闭AOF持久化的，需要通过配置appendonlyfile为yes开启，我们修改配置文件或者在命令行直接使用config set修改，再用config rewrite同步到配置文件。通过客户端修改好处是不用重启redis，AOF持久化直接生效。
AOF工作流程：
- 追加写入redis将每一条命令先添加到缓存区aof_buf，而不是直接写入磁盘，然后根据同步策略将命令一次性写入磁盘。这样做可以减少磁盘I/O次数，提高性能。
- 同步命令磁盘当命令在缓存区中后，redis根据策略将命令写入磁盘。redis提供了三种策略，由配置参数appendfsync决定，下面是每种策略的含义：no：不使用fsync方法同步，而是交给操作系统write函数去执行同步操作，在linux操作系统中大约每30秒刷一次缓冲。这种情况下，缓冲区数据同步不可控，并且在大量的写操作下，aof_buf缓冲区会堆积会越来越严重，一旦redis出现故障，数据丢失严重。always：这种情况下由于每次写命令都写到了文件中, 虽然数据比较安全，但是因为每次写操作都会同步到AOF文件中，所以在性能上会有影响，同时由于频繁的IO操作，硬盘的使用寿命会降低。everysec：数据将使用调用操作系统write写入文件，并使用fsync每秒一次从内核刷新到磁盘。 这是折中的方案，兼顾性能和数据安全，所以redis默认推荐使用该配置。
- 文件重写当开启的AOF时，随着时间推移，AOF文件会越来越大,当然redis也对AOF文件进行了优化，即触发AOF文件重写条件的时候，redis将使用bgrewriteaof对AOF文件进行重写。这样的好处在于减少AOF文件大小，同时有利于数据的恢复。相当于对AOF文件进行了一次压缩。下面是重写的一些策略：重复或无效的命令不写入文件过期的数据不再写入文件多条命令合并写入（当多个命令能合并一条命令时候会对其优化合并作为一个命令写入，例如“RPUSH list1 a RPUSH list1 b" 合并为“RPUSH list1 a b” ）
重写触发条件
AOF文件触发条件可分为手动触发和自动触发：
手动触发：客户端执行bgrewriteaof命令。
自动触发：自动触发通过以下两个配置协作生效：
auto-aof-rewrite-min-size: AOF文件最小重写大小，只有当AOF文件大小大于该值时候才可能重写,4.0默认配置64mb。
auto-aof-rewrite-percentage：当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比，如100代表当前AOF文件是上次重写的两倍时候才重写。
redis开启在AOF功能开启的情况下，会维持以下三个变量
记录当前AOF文件大小的变量aof_current_size。
记录最后一次AOF重写之后，AOF文件大小的变量aof_rewrite_base_size。
增长百分比变量aof_rewrite_perc。
每次当serverCron（服务器周期性操作函数）函数执行时，它会检查以下条件是否全部满足，如果全部满足的话，就触发自动的AOF重写操作：
没有BGSAVE命令（RDB持久化）/AOF持久化在执行；
没有BGREWRITEAOF在进行；
当前AOF文件大小要大于server.aof_rewrite_min_size的值；
当前AOF文件大小和最后一次重写后的大小之间的比率等于或者大于指定的增长百分比（auto-aof-rewrite-percentage参数）
AOF配置文件
auto-aof-rewrite-min-size 64mb#AOF文件最小重写大小，只有当AOF文件大小大于该值时候才可能重写,4.0默认配置64mb。auto-aof-rewrite-percentage 100#当前AOF文件大小和最后一次重写后的大小之间的比率等于或者等于指定的增长百分比，如100代表当前AOF文件是上次重写的两倍时候才重写。appendfsync everysec#no：不使用fsync方法同步，而是交给操作系统write函数去执行同步操作，在linux操作系统中大约每30秒刷一次缓冲。这种情况下，缓冲区数据同步不可控，并且在大量的写操作下，aof_buf缓冲区会堆积会越来越严重，一旦redis出现故障，数据#always：表示每次有写操作都调用fsync方法强制内核将数据写入到aof文件。这种情况下由于每次写命令都写到了文件中, 虽然数据比较安全，但是因为每次写操作都会同步到AOF文件中，所以在性能上会有影响，同时由于频繁的IO操作，硬盘的使用寿命会降低。#everysec：数据将使用调用操作系统write写入文件，并使用fsync每秒一次从内核刷新到磁盘。 这是折中的方案，兼顾性能和数据安全，所以redis默认推荐使用该配置。aof-load-truncated yes#当redis突然运行崩溃时，会出现aof文件被截断的情况，Redis可以在发生这种情况时退出并加载错误，以下选项控制此行为。#如果aof-load-truncated设置为yes，则加载截断的AOF文件，Redis服务器启动发出日志以通知用户该事件。#如果该选项设置为no，则服务将中止并显示错误并停止启动。当该选项设置为no时，用户需要在重启之前使用“redis-check-aof”实用程序修复AOF文件在进行启动。appendonly no #yes开启AOF，no关闭AOFappendfilename appendonly.aof#指定AOF文件名，4.0无法通过config set 设置，只能通过修改配置文件设置。dir /etc/redis#RDB文件和AOF文件存放目录
优点
- 使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的 fsync 策略，比如无 fsync ，每秒钟一次 fsync ，或者每次执行写入命令时 fsync 。AOF 的默认策略为每秒钟 fsync 一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。
- AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行 seek ， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等）， redis-check-aof 工具也可以轻易地修复这种问题。
- Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写：重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
- AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。导出（export） AOF 文件也非常简单：举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
缺点
- 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
- 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。
- AOF 在过去曾经发生过这样的 bug ：因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。（举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试：它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的
3. 混合方式
混合方式就是将AOF和RDB混合使用，同时结合RDB持久化以及AOF持久化混合写入AOF文件。这样做的好处是可以结合 rdb 和 aof 的优点, 快速加载同时避免丢失过多的数据，缺点是 aof 里面的 rdb 部分就是压缩格式不再是 aof 格式，可读性差。
4.0版本的混合持久化默认关闭的，通过aof-use-rdb-preamble配置参数控制，yes则表示开启，no表示禁用，默认是禁用的，可通过config set修改。
混合持久化同样也是通过bgrewriteaof完成的，不同的是当开启混合持久化时，fork出的子进程先将共享的内存副本全量的以RDB方式写入aof文件，然后再将重写缓冲区的增量命令以AOF方式写入到文件，写入完成后通知主进程更新统计信息，并将新的含有RDB格式和AOF格式的AOF文件替换旧的的AOF文件。简单的说：新的AOF文件前半段是RDB格式的全量数据后半段是AOF格式的增量数据
当我们开启了混合持久化时，启动redis依然优先加载aof文件，aof文件加载可能有两种情况如下：
aof文件开头是rdb的格式, 先加载 rdb内容再加载剩余的 aof。
aof文件开头不是rdb的格式，直接以aof格式加载整个文件。
总结
最后
感谢大家看到这里，如果本文有什么不足之处，欢迎多多指教；如果你觉得对你有帮助，请给我点个赞。
也欢迎大家关注我的公众号：程序员麦冬