Redis持久化详解

Bertha 。 2021-09-25 11:40 357阅读 0赞

**目录**

Redis持久化简介

为什么需要持久化

Redis持久化有哪些方式？为什么重点学习RDB和AOF？

快照原理

触发方式：

手动触发：

自动触发：

bgsave运作流程

RDB深入理解

RDB的优缺点

AOF日志原理

为什么采用写后日志？

如何实现AOF

深入理解AOF重写

总结操作

Redis4.0 混合持久化

性能与实践

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

# Redis持久化简介 #

## 为什么需要持久化 ##

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

## Redis持久化有哪些方式？为什么重点学习RDB和AOF？ ##

从严格意义上来讲，Redis提供四种持久化存储方式，RDB、AOF、虚拟内存（VM）、DISKSTORE。

虚拟内存方式，从version 2.4 开始就被官方明确表示不再建议使用，version 3.2 再也找不到任何关于虚拟内存的配置。DISKSTORE 是从version 2.8 提出的一种设想，到目前为止Redis官方也没有在任何版本中明确使用这种方式。 最关键的是目前官方文档上能够看到的Redis对持久化存储的明确支持就只有两种方案。第一种是快照（RDB），第二种是AOF日志。

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

# 快照原理 #

RDB持久化是把当前进程数据生成快照保存到磁盘的过程，由于是某一时刻的快照，那么快照中的值要早于或者等于内存中的值。

## 触发方式： ##

触发RDB持久化的方式有两种：手动触发、自动触发。

### 手动触发： ###

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

### 自动触发： ###

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

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

### bgsave运作流程 ###

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70][]

1.  执行bgsave命令，redis父进程判断是否存在正在执行的子进程，如RDB/AOF子进程，如果存在bgsave命令直接返回（生成RDB、AOF要浪费大量磁盘io资源，如果开启aof，磁盘io有可能成为redis的瓶颈）
2.  父进程执行fork操作创建子进程，fork操作过程中父进程会阻塞，通过info stats 命令查看latest\_fork\_usec选项，可以获取最近一个fork操作的耗时（单位ms）（具体阻塞时间和内存大小有关）
3.  父进程fork完成后，bgsave命令返回“Background saving started”信息并不在阻塞父进程，子进程创建RDB文件，根据父进程内存生成的临时快照文件，完成后对原有的文件进行院子替换。执行lastsave命令可以获取最后一次生成RDB的时间
4.  子进程发送信号给父进程表示完成，父进程更新统计信息。

## RDB深入理解 ##

*  内存中的数据同步到硬盘过程中Redis服务收到数据写操作请求，如何保证数据一致性呢？

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

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

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

*  在进行快照操作的这段时间，如果发生服务崩溃怎么办？

很简单，在没有将数据全部写入到磁盘前，这次快照操作都不算成功。如果出现崩溃的情况，将以上一次完整的RDB快照文件作为恢复内存数据的参考。

*  可以每秒做一次快照吗？

对于快照来说，所谓“连拍”就是指连续地做快照。这样一来，快照的间隔时间变得很短，即使某一时刻发生宕机了，因为上一时刻快照刚执行，丢失的数据也不会太多。但是，这其中的快照间隔时间就很关键了。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 1][]

所以，要想尽可能恢复数据，t 值就要尽可能小，t 越小，就越像“连拍”。那么，t 值可以小到什么程度呢，比如说是不是可以每秒做一次快照？毕竟，每次快照都是由 bgsave 子进程在后台执行，也不会阻塞主线程。

这种想法其实是错误的。虽然 bgsave 执行时不阻塞主线程，但是，如果频繁地执行全量快照，也会带来两方面的开销：

*  一方面，频繁将全量数据写入磁盘，会给磁盘带来很大压力，多个快照竞争有限的磁盘带宽，前一个快照还没有做完，后一个又开始做了，容易造成恶性循环。
 *  另一方面，bgsave 子进程需要通过 fork 操作从主线程创建出来。虽然，子进程在创建后不会再阻塞主线程，但是，fork 这个创建过程本身会阻塞主线程，而且主线程的内存越大，阻塞时间越长。如果频繁 fork 出 bgsave 子进程，这就会频繁阻塞主线程了。

那么，有什么其他好方法吗？此时，我们可以做增量快照，就是指做了一次全量快照后，后续的快照只对修改的数据进行快照记录，这样可以避免每次全量快照的开销。这个比较好理解。

## RDB的优缺点 ##

优点：

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

缺点：

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

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

# AOF日志原理 #

AOF的主要作用是解决了数据持久化的实时性。Redis先执行命令，把数据写入内存，然后才记录日志。AOF 日志存储的是 Redis 服务器的顺序指令序列，AOF 日志只记录对内存进行修改的指令记录，这些命令是以文本形式保存。PS: 大多数的数据库采用的是写前日志（WAL），例如MySQL，通过写前日志和两阶段提交，实现数据和逻辑的一致性。

AOF日志采用写后日志，即先写内存，后写日志。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 2][]

## 为什么采用写后日志？ ##

Redis要求高性能，采用写后日志有两方面的好处？

*  避免额外的检查开销：Redis 在向 AOF 里面记录日志的时候，并不会先去对这些命令进行语法检查。所以，如果先记日志再执行命令的话，日志中就有可能记录了错误的命令，Redis 在使用日志恢复数据时，就可能会出错。
 *  不会阻塞当前的写操作

但这种方式存在潜在风险：

*  如果命令执行完成，写日志之前宕机了，会丢失数据。
 *  主线程写磁盘压力大，导致写盘慢，阻塞后续操作。

## 如何实现AOF ##

AOF日志记录Redis的每个写命令，步骤分为：命令追加（append）、文件写入（write）和文件同步（sync）。

*  命令追加 当AOF持久化功能打开了，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器的 aof\_buf 缓冲区。
 *  文件写入和同步 关于何时将 aof\_buf 缓冲区的内容写入AOF文件中，Redis提供了三种写回策略：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 3][]

Always，同步写回：每个写命令执行完，立马同步地将日志写回磁盘；

Everysec，每秒写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔一秒把缓冲区中的内容写入磁盘；

No，操作系统控制的写回：每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘。

*  三种写回策略的优缺点

上面的三种写回策略体现了一个重要原则：trade-off，取舍，指在性能和可靠性保证之间做取舍。

关于AOF的同步策略是涉及到操作系统的 write 函数和 fsync 函数的，在《Redis设计与实现》中是这样说明的：

为了提高文件写入效率，在现代操作系统中，当用户调用write函数，将一些数据写入文件时，操作系统通常会将数据暂存到一个内存缓冲区里，当缓冲区的空间被填满或超过了指定时限后，才真正将缓冲区的数据写入到磁盘里。 这样的操作虽然提高了效率，但也为数据写入带来了安全问题：如果计算机停机，内存缓冲区中的数据会丢失。为此，系统提供了fsync、fdatasync同步函数，可以强制操作系统立刻将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。

## 深入理解AOF重写 ##

Redis在长期运行过程中，AOF的日志会越来越大，如果实例宕机重启，重放整个AOF日志会非常耗时，导致Redis长时间无法对外提供服务。为了解决AOF文件体积膨胀的问题，Redis提供AOF文件重写机制来对AOF日志瘦身。

*  AOF重写机制

Redis通过创建一个新的AOF文件来替换现有的AOF，新旧两个AOF文件保存的数据相同，但新AOF文件没有了冗余命令。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 4][]

*  AOF重写会阻塞吗？

AOF重写过程是由后台进程bgrewriteaof来完成的。主线程fork出后台的bgrewriteaof子进程，fork会把主线程的内存拷贝一份给bgrewriteaof子进程，这里面就包含了数据库的最新数据。然后，bgrewriteaof子进程就可以在不影响主线程的情况下，逐一把拷贝的数据写成操作，记入重写日志。

所以aof在重写时，在fork进程时是会阻塞住主线程的。

*  AOF日志何时会重写？

有两个配置项控制AOF重写的触发：

auto-aof-rewrite-min-size:表示运行AOF重写时文件的最小大小，默认为64MB。

auto-aof-rewrite-percentage:这个值的计算方式是，当前aof文件大小和上一次重写后aof文件大小的差值，再除以上一次重写后aof文件大小。也就是当前aof文件比上一次重写后aof文件的增量大小，和上一次重写后aof文件大小的比值。

*  重写日志时，有新数据写入咋整？

重写过程总结为：“一个拷贝，两处日志”。在fork出子进程时的拷贝，以及在重写时，如果有新数据写入，主线程就会将命令记录到两个aof日志内存缓冲区中。如果AOF写回策略配置的是always，则直接将命令写回旧的日志文件，并且保存一份命令至AOF重写缓冲区，这些操作对新的日志文件是不存在影响的。（旧的日志文件：主线程使用的日志文件，新的日志文件：bgrewriteaof进程使用的日志文件）

而在bgrewriteaof子进程完成会日志文件的重写操作后，会提示主线程已经完成重写操作，主线程会将AOF重写缓冲中的命令追加到新的日志文件后面。这时候在高并发的情况下，AOF重写缓冲区积累可能会很大，这样就会造成阻塞，Redis后来通过Linux管道技术让aof重写期间就能同时进行回放，这样aof重写结束后只需回放少量剩余的数据即可。

最后通过修改文件名的方式，保证文件切换的原子性。

在AOF重写日志期间发生宕机的话，因为日志文件还没切换，所以恢复数据时，用的还是旧的日志文件。

## 总结操作 ##

*  主线程fork出子进程重写aof日志
 *  子进程重写日志完成后，主线程追加aof日志缓冲
 *  替换日志文件

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 5][]

*  主线程fork出子进程的是如何复制内存数据的？

fork采用操作系统提供的写时复制（copy on write）机制，就是为了避免一次性拷贝大量内存数据给子进程造成阻塞。fork子进程时，子进程时会拷贝父进程的页表，即虚实映射关系（虚拟内存和物理内存的映射索引表），而不会拷贝物理内存。这个拷贝会消耗大量cpu资源，并且拷贝完成前会阻塞主线程，阻塞时间取决于内存中的数据量，数据量越大，则内存页表越大。拷贝完成后，父子进程使用相同的内存地址空间。

但主进程是可以有数据写入的，这时候就会拷贝物理内存中的数据。如下图（进程1看做是主进程，进程2看做是子进程）：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 6][]

在主进程有数据写入时，而这个数据刚好在页c中，操作系统会创建这个页面的副本（页c的副本），即拷贝当前页的物理数据，将其映射到主进程中，而子进程还是使用原来的的页c。

*  在重写日志整个过程时，主线程有哪些地方会被阻塞？

1.  fork子进程时，需要拷贝虚拟页表，会对主线程阻塞。
2.  主进程有bigkey写入时，操作系统会创建页面的副本，并拷贝原有的数据，会对主线程阻塞。
3.  子进程重写日志完成后，主进程追加aof重写缓冲区时可能会对主线程阻塞。

*  为什么AOF重写不复用原AOF日志？

两方面原因：

1.  父子进程写同一个文件会产生竞争问题，影响父进程的性能。
2.  如果AOF重写过程中失败了，相当于污染了原本的AOF文件，无法做恢复数据使用。

# Redis4.0 混合持久化 #

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

Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

这样一来，快照不用很频繁地执行，这就避免了频繁 fork 对主线程的影响。而且，AOF 日志也只用记录两次快照间的操作，也就是说，不需要记录所有操作了，因此，就不会出现文件过大的情况了，也可以避免重写开销。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 7][]

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

# 性能与实践 #

通过上面的分析，我们都知道RDB的快照、AOF的重写都需要fork，这是一个重量级操作，会对Redis造成阻塞。因此为了不影响Redis主进程响应，我们需要尽可能降低阻塞。

*  降低fork的频率，比如可以手动来触发RDB生成快照、与AOF重写；
 *  控制Redis最大使用内存，防止fork耗时过长；
 *  合理配置Linux的内存分配策略，避免因为物理内存不足导致fork失败。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70]: /images/20210923/f48a81fba801445eb53e666796ec7b39.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 1]: /images/20210923/cb450c1592af4316a3dc0b06d19a031c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 2]: /images/20210923/6609791aab6645c4bb241dbd9c9c2c0f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 3]: /images/20210923/3a05c3078a324848a07c4c63c4dc6340.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 4]: /images/20210923/e54ef29d5bcc42acaf6da77863359551.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 5]: /images/20210923/249dd971008b4227ac14a603a2261452.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 6]: /images/20210923/721338ea27854854bc96a491b6bbc58a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppbnd1ZmVpeWFuZw_size_16_color_FFFFFF_t_70 7]: /images/20210923/4f3ef6252b2141318044de0fdc9d1bee.png