Redis持久化

た入场券 2021-09-23 21:00 367阅读 0赞

Redis的数据全部在内存里，如果突然宕机，数据就会全部丢失，因此必须有一种机制来保证Redis的数据不会因为故障而丢失，这种机制就是Redis的持久化机制。

Redis的持久化机制有两种方式，第一种是快照，第二种是AOF日志。快照是一次全量备份，AOF日志是连续的增量备份。快照是内存数据的二进制序列化形式，在存储上非常紧凑，而 AOF 日志记录的是内存数据修改的指令记录文本。AOF日志在长期的运行中会变得无比庞大，数据库重启会加载AOF日志进行指令重放，这个时间会无比漫长，所以需要定期进行AOF重写，进行瘦身操作。

### **快照原理** ###

RDB持久化是把当前进程数据生成快照保存到磁盘的过程，触发RDB持久化过程分为手动触发和自动触发。

触发机制：

1.  save命令：阻塞当前redis服务器，直RDB过程完成为止。（如果内存比较大会造成redis长时间阻塞，这样显然不是我们想要的。线上禁止使用）
2.  bgsave命令：redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般很短（和实例数据大小有关系）

除了执行命令手动触发之外，存在自动触发RDB的持久化机制。

1.  使用save相关配置，如“save m n” 表示m秒内数据集存在n次修改时（可以配置多组条件，其中一个达标就触发），自动触发bgsave
2.  如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
3.  执行debug reload命令重写加载redis时
4.  默认情况下执行shutdown命令时，如果没有开启aof持久化则自动执行bgsave

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

### **COW（Copy On Write）** ###

Redis在持久化时会调用glibc的函数fork产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。子进程刚刚产生时，它和父进程共享内存里面的代码段和数据段.这是 Linux 操作系统的机制，为了节约内存资源，所以尽可能让它们共享起来。在进程分离的一瞬间，内存的增长几乎没有明显变化。子进程做数据持久化，它不会修改现有的内存数据结构，它只是对数据结构进行遍历读取，然后序列化写到磁盘中。但是父进程不一样，它必须持续服务客户端请求，然后对内存数据结构进行不间断的修改。

这个时候就会使用操作系统的 COW 机制来进行数据段页面的分离。数据段是由很多操作系统的页面组合而成（一页4k），当父进程对其中一个页面的数据进行修改时，会将被共享的页面复制一份分离出来，然后对这个复制的页面进行修改。这时子进程相应的页面是没有变化的，还是进程产生时那一瞬间的数据。

子进程因为数据没有变化，它能看到的内存里的数据在进程产生的一瞬间就凝固了，再也不会改变，这也是为什么 Redis 的持久化叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。

### **RDB的载入** ###

和使用save或者bgsave命令不同，RDB的载入是在服务器启动的时候自动执行的，所以Redis并没有专门用于载入RDB的文件命令。值得一提的是：

1.  果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库
2.  据库在主从复制时候会触发RDB加载

### **RDB的优缺点** ###

**优点：**

1.  DB是一个紧凑压缩的二进制文件，某个时间点的上的快照。适合全量复制
2.  redis加载RDB恢复数据远快于AOF的方式

**缺点：**

1.  RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作，频繁执行成本过高。
2.  RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题。

**针对RDB不适合实时持久化的问题，Redis提供了AOF持久化方式来解决。**

--------------------

## **AOF日志原理** ##

AOF的主要作用是解决了数据持久化的实时性，AOF 日志存储的是 Redis 服务器的顺序指令序列，AOF 日志只记录对内存进行修改的指令记录。

Redis 会在收到客户端修改指令后，进行参数校验进行逻辑处理后，如果没问题，就立即将该指令文本存储到 AOF 日志中，也就是先执行指令才将日志存盘。这点不同于mysql、hbase等存储引擎，它们都是先存储日志再做逻辑处理。

Redis在长期运行过程中，AOF的日志会越来越长吗，如果实例宕机重启，重放整个AOF日志会非常耗时，导致Redis长时间无法对外提供服务，所以需要对AOF日志瘦身。

### **AOF重写机制** ###

Redis提供了bgrewriteaof指令用于对AOF日志进行瘦身，原理就是开辟一个子进程对内存进行遍历，转换成一系列Redis的操作指令，序列化到一个新的AOF日志文件中。上文讲到frok运用cow（写时复制技术）技术，所以子进程只能看到fork那一瞬间产生的镜像数据。为了解决这一个问题redis设置了一个 AOF重写缓存区（aof\_rewrite\_bug） 用来存储AOF重写期间产生的命令，等子进程重写完成后通知父进程，父进程把重写缓存区的数据追加到新的AOF文件(注：这里值得注意，AOF重写期间如果有大量的写入，父进程在把aof\_rewrite\_buf写到新的aof文件时会造成大量的写盘操作，会造成性能的下降，redis 4.0以后增加管道机制来优化这里（把aof\_rewrite\_buf追加工作交给子进程去做））

### **命令写入and文件同步** ###

服务器在执行完一个写命令后（如 set k v，lpush k v 等），会把写入命令会追加到aof\_buf（缓冲区）中。后续防止丢失aof\_buf中的数据，在调用linux的glibc提供的fsync函数将aof\_buf中的数据强制刷新到磁盘。

Redis提供了多种AOF缓冲区同步文件策略，由参数appendfsync控制

1.  always: 命令写入aof\_buf后调用系统fsync操作同步到aof文件，fsync完成后线程返回（性能最差，完全取决于磁盘速度。即便如此redis也不能保证一条数据也不丢）
2.  everysec: 命令写入aof\_buf后调用系统write操作，write完成后线程返回。fsync同步文件操作由专门的线程每秒调用一次（默认配置。理论上会丢失1s的数据。）
3.  no：命令写入aof\_bug后调用系统的write操作，不对AOF文件做fsync同步，同步硬盘操作由操作系统负责，通常同步周期30s

### **Redis4.0 混合持久化** ###

重启Redis时，很少使用快照方式恢复内存状态，因为会丢失大量数据，使用AOF日志重放，比快照方式慢很多，实例很大的时候，启动很花费时间。

Redis4.0使用新的持久化选项——混合持久化。在重启的时候，可以先加载RDB内容，然后在重放AOF日志，效率得到很大提升。这里AOF日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量AOF日志。通常这部分AOF日志很小。