Redis持久化

一、什么是持久化

持久化，顾名思义，指的是将短暂的、易失的数据转化为长时间保存，且不易丢失的格式。在数据库的语境中，持久化常常指的是将内存中的数据保存到硬盘或其他长期存储介质中，从而确保即使在系统崩溃、断电或其他突发事件中，数据也不会丢失。

二、Redis持久化的机制

Redis的读写操作都是在内存中，所以Redis性能才会高，但是当Redis重启后，内存中的数据就会丢失，那为了保存内存中的数据不会丢失，Redis实现了数据持久化机制，会把数据保存到磁盘，这样Redis重启就能够从磁盘恢复原有的数据。

1、RDB（快照）

Redis的默认持久化方式是RDB

RDB：是Redis DataBase缩写，按照一定的时间将内存的数据以快照的形式保存到硬盘中，对应产生的数据文件为dump.rdb。

RDB记录的是某一个瞬间的内存数据，记录的是实际数据，因此在数据恢复时，RDB恢复数据的效率比AOF高些。

（1）RDB工作原理 

（2）生成快照的方式：

客户端方式：save命令和bgsave命令

服务端方式：服务器配置自动触发和shutdown命令

客户端方式：

1. bgsave命令：客户端可以使用bgsave命令来创建一个快照，当接受到客户端的bgsave命令时，redis会创建一个子进程，子进程负责将快照写入磁盘中，而父进程继续处理命令请求。(在子进程创建之初，父子进程共享相同内存，知道父进程或子进程对内存进行了写之后，对于被写入的内存的共享就会结束服务)
2. save命令：客户端使用save命令创建一个快照，接收到save命令的redis服务器在快照创建完毕之前将不再响应任何其他命令。

 服务端方式：

1. 服务器通过配置方式来满足自动触发快照进行持久化，管理员需要在redis.conf中设置配置选项，redis会在save选项条件满足之后自动触发一次bgsave命令，如果管理员设置了多个save配置选项，当任意save条件被满足，redis都会触发一次bgsave命令。
2. shutdown命令：当redis通过shutdown指令接受到关闭服务器的请求时，会触发一次save命令，阻塞所有的客户端，不再执行客户端发送的任何命令，在save命令执行完毕后关闭服务器。

（3）优缺点

优点：

1. 只有一个dump.rdb文件，方便持久化。
2. 容灾性好，一个文件可以保存到安全的磁盘中。
3. 性能最大化，子进程来完成写操作，主进程可以继续处理命令，实现IO最大化（使用单独的子进程来进行持久化，主进程不会进行任何IO操作，保证了redis的高性能）。
4. 相对于数据集大时，比AOF的启动效率更高。

缺点： 

1. 数据安全性低，RDB时间是间隔一段时间进行持久化，如果持久化之间redis发生宕机，会发生数据丢失。
2. dump.rdb文件是一个redis中特别的二进制文件，涉及到不同的redis版本，可能会发生版本不兼容问题。

2、 AOF（追加日志文件）

AOF：是Append Only File的缩写。

AOF是指，将redis执行的所有写命令记录到日志文件中，将被执行的写命令写到AOF的文件末尾，当redis重启时，redis会从头到尾执行一次AOF文件所包含的所有写命令，以此回复AOF文件的记录的数据集。

（1） AOF工作原理

Redis 中的 AOF 持久化方式旨在持续地保存服务器上的所有修改操作。每当执行一个会改变数据的命令时，Redis 都会将该命令写入 AOF 文件中。这样，当 Redis 需要恢复数据时，只需执行 AOF 文件中的命令就可以恢复到原来的状态。

AOF持久化的实现主要是以上三步：命令追加、文件写入、文件同步

• 命令追加：将 redis 写操作命令追加到 aof_buf 缓冲区
• 文件写入：周期性地将 aof_buf 缓冲区的命令写入 AOF 文件的内核缓冲区。
• 文件同步：根据配置同步策略，将 AOF 文件缓冲区的内容同步到磁盘。

（2）文件同步策略

1.Always【谨慎使用】：

每次有命令写入时都立即同步。这提供了最高的数据安全性，但效率最低。

解释：如果用户使用了always选项，会将发生系统崩溃时出现的数据丢失减到最少，但因为这种同步策略需要对硬盘进行大量的写入操作，所以redis处理命令的速度会受到硬盘性能的限制。

2.Everysec【推荐】：

每秒同步一次。这是一个权衡安全性和效率的策略。最多只丢失 1 秒的数据

解释：同时保障了数据安全和写入性能，redis每秒一次对AOF文件进行同步，此时AOF文件性能和不使用任何持久化特性时的性能基本相同；通过每秒同步一次AOF文件，redis可以保证，即使系统崩溃，最多丢失一秒之内产生的数据。

3.No【不推荐】：

让操作系统决定最佳的同步时间。这可能导致数据丢失，但提供了最高的效率。

解释：这个选项会对redis性能带来影响，当系统宕机时，丢失的数据量具有不确定性；另外，如果用户硬盘处理写入操作不够快，当缓冲区被等待写入硬盘数据填满时，redis会处于阻塞状态，导致redis的处理命令请求速度变慢。

（3）AOF重写 

AOF文件是以追加的方式记录接收到的写命令的，不断的追加会导致AOF文件过大。
文件过大导致的问题：

1.文件系统的限制：文件系统本身对于文件的大小有限制，无法保存过大文件，如果超出限制，会导致Redis宕机，Redis执行命令速度会降低。

2.追加效率降低：AOF文件采用追加的方式写入文件，每次要遍历寻找到文件尾部，如果文件过大，追加效率会大幅度降低。

3.执行效率降低：如果服务器宕机，AOF文件命令要逐一执行，文件过大导致执行内容过多，影响效率。

AOF重写：用来一定程度上减小AOF文件的体积，解决文件过大的问题。

AOF重写流程：

AOF重写主要有以下四步：

• redis主进程通过fork()系统调用来创建子进程，由子进程负责执行AOF日志的重写操作，生成一个新的AOF文件。
• 在子进程进行AOF重写的同时，redis主进程将新的写操作命令写入AOF重写缓冲区
• 主进程将AOF重写缓冲区的内容写入到新的AOF文件中
• 使用新的AOF文件替换旧的AOF文件

 AOF配置详解

1.当Redis进行AOF重写或快照保存时，怎样避免主进程fsync的延迟？

设置 no-appendfsync-on-rewrite 为 yes。默认是 no。

2.怎样自动触发 AOF 文件重写？

配置 redis.conf 中的 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size 选项
auto-aof-rewrite-min-size 64mb 表示AOF写入文件大小大于64m才能触发重写操作。
auto-aof-rewrite-percentage 100 中的100表示百分比，表示AOF文件的体积比上一次重写之后体积至少大了 “100%” 时会自动触发。

3.如果AOF文件在末尾被截断，Redis怎么办？

使用 aof-load-truncated 选项。如果设置为 yes，Redis 尝试加载并启动，同时发出日志警告；如果为 no，Redis 会中止并拒绝启动。默认是 yes。

4.要开启AOF模式，怎么办？

将 appendonly 设置为 yes。默认是 no。

5.要改变AOF文件的名称，怎么办？

使用 appendfilename 选项。默认名称是 appendonly.aof。

（4） 优缺点

优点：

1. 数据安全，AOF持久化可以通过配置appendfsync属性，设置其记录频率。
2. 通过append模式写文件，即使服务器宕机，也可以通过redis-check-aof工具解决数据一致问题。
3. 更加灵活。AOF机制的 rewrite 模式，AOF文件没被rewrite之前（文件过大时回对命令进行合并重写），可以删除其中的某些命令。

缺点：

1. AOF文件比RDB文件更大，且回复速度更慢。
2. 数据集大时，AOF比RDB启动效率低。

3、混合持久化

混合持久化是 Redis 4.0 新引入的持久化策略，结合了 RDB 的快速恢复和 AOF 的数据完整性的优点。

混合持久化是指Redis在进行RDB快照的同时，将自上一次快照以来的所有写命令（或部分写命令）以AOF的形式附加到RDB文件中。这样生成的文件既是包含某一时刻数据快照的RDB文件，又包含了从该时刻到当前时间点的增量AOF日志。

（1）混合持久化的工作原理

1. 触发RDB快照：混合持久化通常在RDB快照触发条件满足时启动，例如达到预设的时间间隔或数据集变化量。
2. 生成RDB文件：Redis主进程创建一个子进程来执行RDB快照。子进程将当前内存中的数据状态序列化成RDB文件。
3. 记录增量AOF：与此同时，主进程开始记录自上一次RDB快照以来的所有写命令（或者根据配置仅记录部分关键命令）。这些命令被追加到RDB文件末尾，形成一个混合的文件格式。
4. 文件合并与切换：当RDB快照子进程完成并关闭新生成的RDB文件后，主进程会将此文件作为新的持久化数据文件。此时，混合持久化文件包含了完整的数据快照以及后续的增量AOF日志。
5. 重启恢复：在Redis服务器重启时，首先加载RDB文件以快速恢复到某个时间点的数据状态，然后回放混合文件中后续的AOF日志，将数据库状态更新至最近一次写操作。

（2）混合持久化的工作流程

 

 混合持久化的实现主要是靠主进程和子进程共同完成的。

子进程:

子进程进行 AOF 重写：

• 首先创建新的 AOF 文件 appendonly.rdb
• 将 Redis 当前的数据生成 RDB 快照写入 appendonly.rdb 文件的开始部分

主进程

• 主进程先将新的写操作命令写入 AOF 重写缓冲区
• 主进程将 AOF 重写缓冲区的内容追加到 appendonly.rdb

文件的 RDB 数据的末尾

• 使用 appendonly.rdb 文件替换旧的 AOF 文件

（2）优缺点

优点：

1. 快速恢复：由于RDB部分提供了数据的紧凑快照，重启时可以迅速加载大部分数据，显著减少恢复时间。
2. 数据完整性：AOF部分记录了自快照后发生的全部或部分写操作，即使在快照后至Redis停止服务前有数据更新，也能通过回放这部分AOF日志确保数据的完整性。
3. 磁盘空间优化：相较于单独使用AOF，混合持久化文件通常比纯AOF文件小，因为其仅记录了快照后的增量更改，有助于节省存储空间。
4. 可配置性：Redis允许用户根据实际需求配置是否启用混合持久化以及记录哪些类型的写命令，从而在恢复速度、数据完整性和磁盘使用之间取得平衡。

缺点：

1. 稍微复杂：因为它结合了两种技术，所以处理起来比单一的 RDB 或 AOF 要复杂一点。
2. 可能占更多空间：在某些情况下，保存数据的文件可能会比只使用 RDB 或AOF 的文件要大一些。
3. 写入速度：可能会稍慢一些，特别是当数据需要经常被保存到硬盘时