java(优化29) 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 的缩写。

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 文件中。这既保证了快照的完整性，也允许主线程同时对数据进行修改，避免了对正常业务的影响。

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 接收到 “set key value” 命令将数据写入到内存之后，会按照如下格式写入 AOF 文件：

• *3：表示当前指令分为三个部分，每部分都是 “$ + 数字” 开头，紧跟后面是该部分具体的命令、键、值

• 数字：表示这部分的命令、键、值占用的字节大小。比如 “$3” 表示这部分包含三个字节，也就是 set 指令。

  写后日志的好处

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

  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 缓冲区，由操作系统决定何时写回磁盘。

  3.AOF重写机制

  由于 AOF 记录的是一个个指令的内容，这就会导致保存的文件太大，另外，故障恢复的时候需要执行每一个指令，如果日志文件太大，整个恢复过程就会非常慢。为此，Reids 设计了 AOF 重写机制，提供了 bgrewriteaof 命令用于对 AOF 文件进行瘦身。

  其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中，序列化完毕后再将操作期间发生的增量 AOF 日志追加到这个新的 AOF 日志文件中，追加完毕后立即替换旧的 AOF 日志文件。瘦身工作就完成了。

  重写机制有“多变一”的功能，将旧日志中的多条指令，在重写后就变成了一条指令。如下所示：三条 lpush 命令，经过 AOF 重写后生成一条，对于多次修改的场景，缩减效果明显。

 

重写过程

和 AOF 日志由主线程写回不同，重写过程实际是由后台子进程 bgrewriteof 完成的，这也是为了避免阻塞主线程，导致性能下降。

总的来说，一共出现两个日志，一次内存数据拷贝，分别是旧的 AOF 日志和新的 AOF 重写日志和Redis 数据拷贝。大致流程如下图所示：

在上图中，Redis 会将重写过程中接收到的“写”指令操作同时记录到旧的 AOF 缓冲区和新的 AOF 重写缓冲区，这样重写日志也保存了最新的操作，等到拷贝数据的所有操作记录重写完成后，重写缓冲区记录的最新操作也会写到新的 AOF 文件中。

每次 AOF 重写时，Redis 会先执行一次内存拷贝，用于遍历数据生成重写记录。防止 AOF 重写过程失败，导致原 AOF 文件被污染，无法做恢复使用。

使用两个日志可以保证在重写过程中，新写入的数据不会丢失，并且保持数据的一致性。

4.AOF 的优点和缺点

优点

• AOF比RDB可靠。可以灵活制定不同的fsync策略。

• AOF日志文件是一个纯追加的文件。就算是遇到突然停电的情况，也不会出现日志的定位或者损坏问题。

• 当AOF文件过大时，Redis会自动在后台进行重写。

• AOF以命令格式存储于文件中，在数据恢复时，AOF文件比RDB文件更容易让开发人员看懂，并加以修改。

缺点

• 在相同的数据集下，AOF文件的大小一般会比RDB文件大。

• 在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平。

混合日志模型

重启 Redis 时，我们很少使用 RDB 来恢复内存状态，因为可能丢失大量数据。通常采用 AOF 日志重放，但是重放 AOF 日志性能相对 RDB 来说要慢很多，在Redis实例很大的情况下，启动需要花费很长时间。

Redis 4.0 为了解决这个问题，提供了一个新的持久化选项--混合持久化，将 RDB 文件的内容和增量 AOF 日志文件存放到一起，这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分日志很小。

在 Redis 重启的时候，先加载 RDB 的内容，然后再重放增量 AOF 日志，这样的操作既保证了 Redis 重启速度，又降低数据丢失风险。

总结

• Redis 提供 RDB 快照持久化方案，记录某一时刻数据状态

• Redis 通过写时复制技术设计了BGSAVE，避免执行快照期间对读写指令的影响。

• Redis 提供了 AOF 写后日志持久化方案，记录每一条操作指令。

• Redis 通过 AOF 重写方案，避免 AOF文件过大。

• Redis 提供了混合持久化的方案，RDB + AOF 实现持久化保证数据可靠性，同时支持故障后的数据快速恢复。