引言
Redis作为一款高性能的键值存储系统，广泛应用于缓存、消息队列、会话存储等多种场景，成为提升应用性能的关键组件。作为内存数据库，它存储在内存中的数据在服务器重启或发生意外崩溃时将会丢失。所以需要持久化机制能够将内存中的数据保存到磁盘上，从而在Redis服务停止或重启后能够恢复数据，保证数据的安全性。
在实际开发中的一些通用方案是业务数据最终都保存在DB中，所以也可以从数据库中恢复Redis数据。但是这种方式，会造成数据库的性能瓶颈，特别是在大量Redis数据需要恢复的时候。并且Redis中缓存的数据，会经过一些特殊的处理，跟DB中表数据可能会不一致，所以从DB中恢复Redis数据还需要一些特殊的业务梳理。
所以就需要从Redis自身出发会解决这个问题，Redis设计了两种主要的持久化机制：RDB和AOF。实际上，对于持久化方案，官方文档中给出了三种方式：RDB，AOF，RDB+AOF
图片
关于Redis持久化机制的官方文档：Redis persistence | Docs
Redis持久化方式
Redis提供了两种核心的持久化策略：RDB（快照）和AOF（仅追加日志），随着Redis版本的演进，还引入了混合持久化的方式，进一步优化了Redis的持久化。
RDB
RDB，即Redis Database，是一种快照式持久化方式，它通过定期创建数据集的快照来实现数据的持久存储。在预设条件（如时间间隔、键值变化次数）满足时，Redis会生成当前内存中所有数据的备份文件。当Redis服务需要重新启动时，可以直接加载这些RDB文件，从而快速恢复数据。由于RDB文件是二进制格式，加载速度通常较快。生成快照有自动触发和手动触发两种方式。
自动触发
Redis会将数据集的快照保存到名为dump.rdb的二进制文件中，保存到磁盘上。我们可以通过Redis配置(redis.conf文件)，使其在数据集中至少有M个(changes)更改时，每N秒(seconds)自动保存一次数据集。
save [ ...]# 生成的rdb文件名称
dbfilename dump.rdb
# rdb文件保存路径，可自定义
dir ./
# rdb快照保存配置
save 3600 1 300 100 60 10000
# 如果至少进行了1次更改，那么在3600秒（1小时）后保存；
# 如果至少进行了100次更改，那么在300秒（5分钟）后保存；
# 如果至少进行了10000次更改，那么在60秒后保存。
# 关闭RDB快照
save ""当Redis服务正常关闭时，如果没有启用AOF（Append Only File）持久化，它也会执行一次RDB快照，确保数据被保存到磁盘上。
手动触发
我们还可以通过调用SAVE或BGSAVE命令来手动触发快照保存。这两个命令的区别在于执行数据持久化操作时是否阻塞主线程。
SAVE命令
当执行SAVE命令时，Redis会直接调用rdbSave函数来创建数据快照，并将当前数据集写入到磁盘上的RDB文件中。这是一个同步操作，在保存过程期间，Redis的主进程会被阻塞，无法处理任何其他客户端的请求，直到整个保存操作完成。所以，如果数据集较大，此操作可能会导致Redis服务在较长时间内无法响应，影响服务的可用性。
BGSAVE命令
使用BGSAVE命令时，Redis会通过操作系统fork()调用创建一个子进程，由这个子进程负责执行rdbSave函数和数据持久化工作，即创建数据快照并写入RDB文件。持久化操作在子进程中进行，Redis的主进程（父进程）可以继续处理来自客户端的请求，不会因为持久化操作而阻塞。当子进程完成快照创建后，会向主进程发送一个信号，通知任务完成，然后子进程关闭。
BGSAVE命令执行流程.png
具体执行流程如下：
1. 当Redis客户端发出BGSAVE命令，或者根据配置规则自动触发BGSAVE操作时，持久化进程开始
2. Redis主进程检查是否有正在进行的子进程正在执行BGSAVE或AOF rewrite操作。如果存在这种操作，为了避免资源竞争和数据一致性问题，主进程不会再次发起BGSAVE，可能直接返回一个错误或忽略此次请求。
3. 如果没有其他持久化操作正在进行，主进程会执行fork()系统调用来创建一个子进程。fork()调用在执行时会暂时阻塞主进程，直到子进程完全创建。这个过程中，Redis的内存数据不会被复制，而是通过操作系统实现的写时复制（Copy-On-Write, COW）机制共享给子进程。
4. 子进程开始工作，它将内存中的数据逐步写入到一个新的临时RDB文件中。这个过程对主进程是透明的，不会影响主进程处理客户端的读写请求。
5. 当所有数据写入完毕后，子进程会使用原子操作（通常借助操作系统提供的rename函数）将临时RDB文件替换为正式的RDB文件。保证RBD文件的完整性。
6. 完成上述步骤后，子进程会向主进程发送一个信号，告知BGSAVE操作已完成。
RDB优缺点
优点
• 快速恢复：RDB文件加载速度非常快，因为它直接将数据载入内存而无需逐条执行命令，适合用于快速重启服务后的数据恢复。
• 资源占用低：RDB文件（二进制文件）通常较小，占用磁盘空间少，备份和传输更加高效。
缺点
• 数据丢失风险：如果Redis在两次快照之间崩溃，那么从上一次快照之后的所有数据变更将会丢失。因此，RDB更适合对数据实时性要求不高，但重视恢复速度的场景。
• 无法进行部分恢复：一旦发生故障，只能整体恢复到最近一次快照的状态，无法选择性恢复特定数据。
几个常见的面试问题
• 如果我们的Redis内存的数据比较大（可能给Redis分配的内存较大），我们生成快照保存到磁盘，就会花费的时间要久一些，如果此时Redis的主进程依然还要在处理一些写数据的请求，那么我们如何保证数据一致性呢？
有上述RDB的执行流程中可以看出，主进程通过写时复制，将数据共享给子进程。在持久化操作开始时，父子进程共享相同的内存空间，直到任一进程尝试修改数据。当主进程接收到写操作请求并需要修改数据时，操作系统会为被修改的数据分配新的内存空间，保持原数据不变供子进程快照使用。即便在快照生成期间有写操作，也能保证快照数据反映的是快照操作开始那一刻的数据状态，确保了数据的一致性。
图片
image.png
• 在生成快照的时候，Redis服务跪了，数据会不会丢失？ 在上述BGSAVE命令执行流程时，在最后的写入磁盘时，子进程会使用原子操作将临时RDB文件替换为正式的RDB文件，保证RBD文件的完整性。也就是说Redis在执行BGSAVE命令生成快照时，会先将数据写入到一个临时的RDB文件中，而不是直接覆盖原有的RDB文件。只有当新的快照完全且成功地写入磁盘之后，才会用这个新的快照文件替换掉旧的RDB文件。这一过程是原子性的，确保了要么新快照完全成功，要么不会有任何改动，从而避免了部分写入导致的文件损坏，避免数据的丢失。
• 快照的生成时间间隔是不是越小越好？如何合理的设置？ 对于RDB生成快照来做数据持久化，就是通过连续的生成数据快照将数据保存到磁盘。一单服务发生故障，那么我们就可以通过磁盘上的文件恢复数据。那么，为了防止数据丢失，或者数据丢失过多时，我们可以通过减少时间间隔来实现，也就是说，最好可以一直不停的生成快照，这样就可以达到数据不丢失的目的。
图片
如上图，T0时刻生成了一次快照，那么在t时刻时发生了一次数据修改写入，在写入后到生成下一次快照之前，发生了故障，那么我们恢复数据时，因为T0+t时刻的快照还没生成，数据恢复时只能使用T0时刻的快照，那么在t时刻发生的数据写入就会丢失。所以t时刻的间隔如果变的更小，就会多生成快照，就有很大的几率减少数据丢失的。
那么是不是说这个生成快照的间隔越小越好，甚至说1秒生成一次快照？因为从BGSAVE的执行流程上看，它是通过fork一个子进程去实现快照的生成，并不会阻塞主进程的数据写入。
事实上，这种说法是错误的。理论上，缩短快照间隔可以减少数据丢失的风险，因为一旦系统崩溃，可以恢复到更接近崩溃时间点的数据状态。但是，过于紧密的快照间隔会引发大量的磁盘I/O操作，可能导致数据写操作堆积，反而影响数据的一致性。
并且，虽然Redis使用BGSAVE命令在子进程中生成快照，避免了主线程的长时间阻塞，但是fork子进程的操作本身是阻塞的，并且内存越大，fork操作所需的时间越长。频繁的fork会导致服务在短时间内频繁阻塞，影响响应速度。
那么，如果我们可以只对增量的数据进行快照保存，在第一次进行全量的快照保存后，后续的快照都只对增量的数据（其实这个比较很好理解，这种方案我们也很常见，比如我们在对接一些第三方系统时，在拉取数据时，我们在第一次全量拉去后，后面的数据都只会拉去变化的数据）。那么对于增量的数据，首先我们要知道那些数据变化了，此时，就需要Redis的另外一种机制：AOF了。
AOF
AOF（Append Only File）持久化是一种以日志形式记录每次写操作的方式，以此来保证数据的持久性。与RDB不同，它提供了更高的数据完整性保障，因为其记录了从Redis启动以来的所有写操作，理论上可以做到数据零丢失。
每当有写命令（如SET、HSET等）被执行时，Redis就会将该命令以明文形式追加到AOF文件的末尾。这意味着AOF文件随着时间推移会不断增长，记录着Redis服务器上的所有数据修改历史。
并且AOF采用的是一种"写后日志"机制，即Redis在处理写命令时，先执行写操作，将数据变更写入内存，然后才将该操作命令追加到AOF日志文件中。
写后日志这种机制与一些数据库系统采用的“预写日志”策略恰好相反，后者是在实际数据写入前先记录日志。
为什么采用写后日志？
1. 性能考虑：通过先执行写命令，Redis可以更快地响应客户端，因为写入内存的速度远快于写入磁盘。这样可以减少客户端等待时间。
2. 简化实现：写后日志避免了在记录日志之前对命令进行语法检查的需要。如果先记录日志再执行命令，错误的命令也可能被记录，导致在使用日志恢复数据时出现问题。而在Redis中，因为命令已经执行成功，所以写入日志的命令都是已验证过的，可以安全重放。
3. 简化恢复逻辑：在Redis重启时，通过重放AOF日志中的命令来恢复数据状态，由于这些命令都是曾经成功执行过的，理论上可以无误地重建内存数据结构，降低了数据恢复的复杂度。
当然这中机制也存在着一些潜在风险，比如数据丢失风险，如果在命令执行后、但未记录到AOF日志前发生故障，这部分数据更新将丢失。
AOF实现流程
1. 命令追加（Append）: 当Redis服务器配置开启了AOF持久化功能后，每当执行一个写命令（如SET、HSET、LPUSH等），服务器并不会立即写入到磁盘，而是先将这条命令以Redis协议的格式追加到内存中的一个缓冲区，即aof_buf。
这样做是为了减少直接磁盘I/O的频率，提高写入命令的处理速度。
2. 文件写入（Write）: 缓冲区中的内容并不会一直停留，而是会按照一定的策略（由配置项appendfsync控制）被写入到AOF文件中。AOF提供了三种同步策略来控制命令写入AOF文件：
• always：每个写命令都会立即同步到磁盘，最安全但性能消耗最大。
• everysec（默认）：每秒执行一次fsync操作，平衡了数据安全性与性能。最多丢失一秒的数据。
• no：完全依赖于操作系统来决定何时将数据写入磁盘，性能最佳但可能丢失一秒内的数据。
3. 文件同步（Sync）: 文件同步操作是将内存中已写入AOF文件的数据真正持久化到磁盘上。上述写入AOF文件策略的不同，同步操作的时机也会有所不同。文件同步系统调用是同步操作的核心，它确保了缓冲区中的数据被物理写入磁盘，从而在硬件故障时也能保证数据不丢失。
AOF重写机制
随着时间的推移，AOF文件会因为不断追加写命令而逐渐增大，这不仅占用大量磁盘空间，还会影响数据恢复的速度。AOF重写机制通过生成一个更紧凑的新AOF文件来解决这个问题，新文件仅包含重建当前数据集状态所需的最小命令集合，从而替代原有的庞大AOF文件。
AOF重写可以通过手动执行BGREWRITEAOF命令来触发，也可以通过配置自动触发。自动触发的条件通常是AOF文件大小增长到一定比例（如通过auto-aof-rewrite-percentage配置）或达到一定的最小尺寸（如通过auto-aof-rewrite-min-size配置）。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb类似RDB的BGSAVE命令的工作机制，当重写命令发出后，Redis会通过fork()系统调用创建一个子进程。子进程开始遍历Redis内存中的数据结构，对每个键值对执行相应最少的写命令（如SET、HMSET等），将这些命令写入到一个新的临时AOF文件中。这个过程中，子进程不会处理任何网络请求，也不会影响主进程处理客户端命令的能力。
与RDB不同的是，在子进程重写期间，主进程会继续接收和处理客户端的写请求。为了避免这些新命令丢失，主进程会将它们追加到一个内存缓冲区（AOF重写缓冲区）中。
一旦子进程完成重写，会将临时AOF文件替换掉旧的AOF文件。（为了保证数据一致性，这一过程通常需要原子操作。）在新AOF文件替换旧文件后，主进程会将之前累积在AOF重写缓冲区中的命令追加到新AOF文件的末尾，确保所有数据变更都得到记录。
AOF重写流程.png
如何配置AOF
默认情况下，Redis是没有开启AOF的，可以通过配置redis.conf文件来开启AOF持久化。
# 开启AOF，默认为no，关闭
appendonly yes
# AOF文件名
appendfilename "appendonly.aof"
# 控制AOF fsync策略
appendfsync everysec
# 文件重写策略
aof-rewrite-incremental-fsync yes
# AOF重写触发条件，当AOF文件增长到上一次重写后大小的百分比时触发
auto-aof-rewrite-percentage 100
# 触发重写的最小AOF文件大小
auto-aof-rewrite-min-size 64mb
# 在Redis启动时如何加载AOF文件，默认为yes
aof-load-truncated yes
# aof重写期间是否同步
no-appendfsync-on-rewrite noAOF的优缺点
优点
• 几乎可以实现数据的零丢失，即使在服务器崩溃后也能恢复到最新状态。
• 通过重写机制可以有效控制文件大小，且在极端情况下，即使AOF文件损坏，也往往能通过跳过错误命令来恢复大部分数据。
缺点
• AOF文件会不断膨胀，占用大量磁盘空间。
• AOF在服务器重启时需要逐条执行命令来恢复数据，这会消耗更多时间。
几个常见的面试题
• AOF重写会阻塞主进程吗？ 由上述AOF重写流程中，主进程执行AOF重写命令时，类似RDB的BGSAVE命令，也会fork出来一个子进程用于AOF的重写，此时并不会阻塞主进程的读写操作。当然，在fork子进程时会阻塞。
• 当AOF重写时，此时的写操作的数据会不会丢失？ 由AOF重写流程，在子进程执行重写AOF时，如果此时有数据写操作，此时仍然由主进程完成，同时主进程再把数据写入内存后，会把命令写到一个内存缓冲区，也就是AOF重写缓冲区，在子进程完成AOF重写，替换旧的AOF文件，生成新的AOF文件之后，会通知主进程，此时主进程会讲重写缓冲区的命令追加到新的AOF文件之后。这样就保证数据的完整性。
• 为什么AOF重写不复用原AOF日志？ AOF重写不直接复用原AOF日志的原因主要是为了确保数据的一致性和提高重写效率。AOF重写的目的在于生成一个尽可能小的新AOF文件，该文件仅包含重建当前数据集状态所需的最少命令集。直接编辑原AOF文件难以直接去除冗余命令（比如某条数据可能有数次的变更后产生，其以前的命令就意义不大了）。从AOF重写流程上看，Redis会遍历内存数据，将可以实现数据的最简洁的命令写入到临时的AOF文件。
Redis在执行AOF重写时，主进程仍继续处理客户端命令。如果直接修改原AOF文件，就需要复杂的并发控制来防止数据混乱，而使用新文件重写可以避免这种复杂性。通过子进程执行重写，与主进程的命令处理互不影响。
如果在尝试修改原AOF文件的过程中遇到错误或系统崩溃，可能会导致AOF文件损坏，进而影响数据恢复。使用独立的新文件进行重写，即便过程中出现问题，原AOF文件依然可用。
并且，原AOF文件可能非常大，直接在原文件上进行编辑操作可能会非常缓慢，影响Redis的服务性能。另外，文件系统的直接编辑操作通常比顺序写入新文件更耗时，尤其是在有大量随机读写的情况下。
RDB与AOF的混合使用
为了同时获得RDB的快速恢复速度和AOF的高度数据完整性，Redis支持将这两种持久化策略结合起来使用。混合使用RDB和AOF，取其二者的优点，可以实现数据安全性和恢复效率的最佳平衡。
在混合持久化模式下，Redis首先利用RDB文件快速恢复到某个时间点的数据库状态，然后通过重放AOF日志来补充RDB快照之后的数据变更。RDB作为基础恢复，RDB快照提供了某一时间点的全量数据视图，重启时可以迅速加载到内存，快速使服务可用。而AOF补充细节，AOF日志用于填补从RDB快照以来的数据变动，使得Redis能够逐步恢复到崩溃或重启前的最新状态。
比如，针对RDB快照设置生成间隔的示例，我们使用AOF记录写命令，当某一时刻宕机后，恢复数据时，我们可以从AOF中恢复上一次备份到这次宕机时保存的写操作对应的数据，当数据恢复之后，再使用RDB进行生成快照，然后再清空AOF文件。
图片
Redis重启时判断是否开启aof，如果开启了aof，那么就优先加载aof文件；
这种方式的优势在于：结合RDB的快速加载能力和AOF的细粒度恢复，达到了数据安全性和服务恢复速度的双重优化。根据业务对数据安全等级和恢复时间的要求，可以灵活调整RDB与AOF的比重和策略。通过合理配置RDB保存频率和AOF重写策略，可以有效管理磁盘空间使用，避免不必要的资源浪费。
生产环境的建议
在生产环境进行Redis持久化时，我们可以从以下几个方面考虑：
1. 如果存储在Redis中的数据相对不敏感或能便捷地重新生成，可以选择暂时关闭持久化功能，以减少资源消耗。这样即使偶发数据丢失，也能通过其他机制迅速恢复数据。比如一些数据相对于DB来说，并没有经过一些特殊处理，可以直接从DB中进行恢复，相当于直接在DB做备份。
2. 在同一台服务器部署多Redis实例时，要注意协调各实例的持久化操作（如RDB快照或AOF重写），避免它们同时进行，以免引发内存、CPU或I/O资源的竞争，推荐采取串行执行的方式，确保系统稳定运行。
3. 如果配置了Redis的主从，我们可以指定一个或多个从节点专门负责数据备份处理，这样主节点就能专注于处理客户端请求，提高整体服务的响应速度和可用性。
4. 结合使用RDB和AOF两种持久化方式，可以实现数据恢复的速度与完整性之间的一种最佳平衡。RDB提供快速恢复的能力，而AOF则能更详尽地记录每一步操作，两者互补，确保数据完整性。
