Redis持久化：RDB和AOF_Redis

Redis 数据存储在内存中，如果不想办法将数据保存到硬盘上，一旦Redis重启(退出/故障)，内存的数据将会全部丢失。我们肯定不想 Redis 里的数据由于某些故障全部丢失(导致所有请求都走 MySQL)，即便发生了故障也希望可以将Redis原有的数据恢复过来，这就是持久化的作用。

Redis 提供了两种不同的持久化方法来将数据存储到硬盘里边：

**RDB(Redis Database)**，将某一时刻的所有数据保存到一个 RDB 文件中。
**AOF(append-only-file)**，当Redis服务器执行写命令的时候，将执行的写命令保存到 AOF 文件中。

RDB内存快照，让宕机快速恢复

1.什么是RDB内存快照？

在 Redis 执行“写”指令的过程中，内存数据一直会变化，所谓内存快照，指的就是 Redis 内存中数据在某一时刻的状态数据，好比时间定格在某一时刻。当我们拍照时，通过照片就能把某一时刻的瞬间画面完全记录下来。Redis 跟这个类似，就是把某一刻的数据以文件的形式拍下来，写到磁盘上，这个快照文件叫做 RDB 文件，RDB 就是 Redis Database 的缩写。

Redis持久化：RDB和AOF

2.生成RDB的策略

Redis 并不会在每次执行“写”指令的时候都触发 RDB 写磁盘，只需要在执行内存快照的时候写磁盘，这样既保证了唯快不破，还实现了持久化，宕机快速恢复。

我们知道 Redis 的单线程模型决定了我们要尽可能地避免会阻塞主线程的操作，所以就需要尽可能地避免 RDB 文件生成阻塞主线程。为此Redis提供了两个指令用于生成 RDB 文件：

SAVE：会阻塞 Redis 服务器进程，服务器不能接收任何请求，直到 RDB 文件创建完毕为止。
BGSAVE：fork 出一个子进程，由子进程来负责创建 RDB 文件，服务器进程可以继续接收请求。

除了手动调用 SAVE 或者 BGSAVE 命令生成 RDB 文件之外，我们可以使用配置的方式来定期执行：在默认的配置下，如果以下的条件被触发，就会执行 BGSAVE 命令。

save 900 1              #在900秒(15分钟)之后，至少有1个key发生变化，
save 300 10             #在300秒(5分钟)之后，至少有10个key发生变化
save 60 10000           #在60秒(1分钟)之后，至少有10000个key发生变化

3.RDB实现原理

在RDB执行期间为了保证快照的数据一致性，只能处理读操作，不能修改正在执行快照的数据，这种场景，Redis 是允许的。那 Redis 是如何实现一边处理写请求，同时生成RDB文件的呢？

Redis 使用操作系统的多进程写时复制技术 COW（Copy On Write）来实现快照的持久化。

Redis 在持久化是会调用 glibc 的函数（linux系统中最底层的api）fork产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。子进程刚刚产生时，它和父进程共享内存里面的代码段和数据段，这时可以将父子进程想象成一个连体婴儿，共享身体。这是Linux操作系统的机制，为了节约内存资源，所以尽可能让它们共享起来，在进程分离的一瞬间，内存的增长几乎没有明显的变化。

BGSAVE 子进程可以共享主线程的所有内存数据，读取主线程的数据并写入到 RDB 文件。当主线程执行写指令修改数据的时候，这个数据就会复制一份副本，BGSAVE 子进程读取这个副本数据写到 RDB 文件。

在执行 SAVE 或 BGSAVE 命令创建一个新的 RDB 文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到新创建的RDB 文件中。这既保证了快照的完整性，也允许主线程同时对数据进行修改，避免了对正常业务的影响。

Redis持久化：RDB和AOF

4.RDB的优缺点

优点

RDB 文件是一个很简洁的单文件，采用二进制 + 数据压缩的方式写磁盘，文件体积小，数据恢复速度快。
RDB 的性能很好，需要进行持久化时，主进程会 fork 一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。

缺点

RDB 容易造成数据的丢失。假设每5分钟保存一次快照，如果 Redis 因为某些原因不能正常工作，那么从上次产生快照到 Redis 出现问题这段时间的数据就会丢失了。
RDB 使用 fork() 产生子进程进行数据的持久化，会阻塞主线程，如果数据比较大的话可能就会花费点时间，造成 Redis 停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时间甚至会到1秒。

另外，过于频繁的执行全量数据快照，有两个严重的性能开销：

频繁生成 RDB 文件写入磁盘，磁盘压力过大。可能会出现上一个 RDB 还未完成，下一个又开始生成，陷入死循环。
fork 出 BGSAVE 子进程这个动作本身会阻塞主线程，主线程的内存越大，阻塞时间越长。

AOF写后日志，避免宕机数据丢失

1.什么是AOF写后日志？

AOF（Append Only File）写后日志，AOF 持久化就是将修改数据库状态的命令保存到 AOF 文件中，被写入的命令都是以 Redis 的命令请求协议格式保存的，Redis 的命令请求协议是纯文本格式。

假设 AOF 日志记录了 Redis 实例创建以来所有的修改指令序列，那么就可以通过一个空的 Redis 实例顺序执行所有的指令，也就是“重放”，来恢复Redis当前实例的内存数据结构的状态。

写后日志和写前日志的对比

写前日志（WAL，Write Ahead Log）：在实际写数据之前，将修改的数据写到日志文件中，故障恢复得以保证。比如 MySQL Innodb 存储引擎中的 redo log（重做日志）便是记录修改的数据日志，在实际修改数据前先记录修改日志再执行修改数据。

写后日志：先执行“写”指令请求，将数据写入内存，再记录日志。

Redis持久化：RDB和AOF

日志格式

当 Redis 接收到 “set key value” 命令将数据写入到内存之后，会按照如下格式写入 AOF 文件：

*3：表示当前指令分为三个部分，每部分都是 “$ + 数字” 开头，紧跟后面是该部分具体的命令、键、值
数字：表示这部分的命令、键、值占用的字节大小。比如 “$3” 表示这部分包含三个字节，也就是 set 指令。

Redis持久化：RDB和AOF

写后日志的好处

写后日志避免了额外的检查开销，不需要对执行的命令进行语法检查。如果使用写前日志的话，就需要先检查语法是否有误，否则日志记录了错误的命令，在使用日志恢复的时候就会报错。另外，写后记录日志，避免了阻塞当前“写”指令的执行。

2.写回策略

使用 AOF 也不是万无一失的，假如 Redis 刚执行完指令，还没记录日志就宕机了，就有可能丢失这个命令的相关数据；还有， AOF 避免了当前命令的阻塞，但是可能会给下一个命令带来阻塞的风险。AOF 日志是主线程执行的，将日志写入磁盘过程中，如果磁盘压力过大就会导致磁盘写操作很慢，导致后续的“写”指令阻塞。

发现了没，这两个问题与磁盘写回有关，如果能合理控制“写”指令执行完后 AOF 日志写回磁盘的时机，问题就可以迎刃而解。

为了提高文件的写入效率，当用户调用 write 函数，将一些数据写入到文件时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里，等到缓冲区的空间被填满或者超过了制定的限制之后，才真正将缓冲区中的数据写入到磁盘里面。

这种做法虽然提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里的写入数据将会丢失。为此系统提供了 fsync 和 fdatasync 两个同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。

与之相对应 Redis 提供了 AOF 配置项 appendfsync 写回策略来控制 AOF 持久化功能的效率和安全性。

appendfsync always     # 同步写回，写指令执行完毕立即将 aof_buf 缓冲区中的内容写到 AOF 文件。
appendfsync everysec   # 每秒写回，写指令执行完毕，把日志写到 aof_buf 缓冲区，每隔一秒同步到磁盘，该策略为AOF的默认策略。
appendfsync no         # 操作系统控制，写指令执行完毕，把日志写到 aof_buf 缓冲区，由操作系统决定何时写回磁盘。