Redis持久化机制

一. Redis应用概述

Redis是一种高性能的KV键值对存储数据库，通常用作数据库、缓存和消息队列等。它支持多种数据结构，如字符串、哈希表、列表、集合和有序集合。Redis具有快速存取和实时响应的特点，广泛应用于Web开发、大数据处理和实时分析等领域。需要注意的是，Redis是一个内存数据库，数据主要存储在内存中，一旦服务器出现故障或断电，数据可能会丢失。为了解决这个问题，Redis提供了持久化机制，将数据保存到硬盘中，以便在服务器重启后恢复数据。

二. Redis持久化机制

当前，Redis提供了两种持久化机制：RDB（Redis DataBase）和AOF（Append Only File），以及AOF与RDB两者结合的混和模式。

1. RDB（Redis DataBase）持久化机制

（1）原理

RDB 是 Redis 默认的持久化方式，它会在指定的时间间隔内将内存中的数据集快照以二进制的形式写入到磁盘中的一个二进制文件（默认文件名为 dump.rdb）。当 Redis 重启时，会读取该文件中的数据来恢复数据库状态。

Redis 可以通过创建快照来获得存储在内存里面的数据在 某个时间点 上的副本。Redis 创建快照之后，可以对快照进行备份，可以将快照复制到其他服务器从而创建具有相同数据的服务器副本，还可以将快照留在原地以便重启服务器的时候使用。

触发RDB持久化的方式有2种，分别是手动触发 和自动触发。

A. 手动触发

• 使用save命令 ：阻塞当前Redis服务器，直到RDB过程完成为止，对于内存比较大的实例会造成长时间阻塞，线上环境不建议使用。示例 ：在 Redis 客户端中输入 SAVE 命令，即可手动触发 RDB 持久化。执行成功后，Redis 会返回 "OK"，并生成一个 RDB 文件（默认文件名为 dump.rdb）。

• 使用bgsave命令 ：Redis进程执行fork操作创建子进程，RDB持久化过程由子进程负责，完成后自动结束。阻塞只发生在fork阶段，一般时间很短。示例 ：在 Redis 客户端输入BGSAVE命令，执行成功后，Redis 返回 "Background saving started"，然后在后台进行 RDB 持久化操作。

B. 自动触发

• Redis.conf中配置save m n配置项，即在m秒内有n次修改时，自动触发bgsave生成rdb文件；
• 主从复制时，从节点要从主节点进行全量复制时也会触发bgsave操作，生成当时的快照发送到从节点；
• 执行debug reload命令重新加载Redis时也会触发bgsave操作；
• 默认情况下执行shutdown命令时，如果没有开启AOF持久化，那么也会触发bgsave操作；

（2）优点

• 数据完整性要求不高时性能最优 ：采用 fork() 机制来执行持久化操作，由父进程负责处理客户端请求，子进程负责将内存中的数据写入到临时 RDB 文件。写入完成后，再替换旧的 RDB 文件，最大限度地避免了父进程的性能损耗，保证了 Redis 服务的高性能。
• 备份和灾难恢复方便 ：一个紧凑的 RDB 文件包含了 Redis 在某个时间点上的完整数据，非常适合进行备份和灾难恢复操作，例如可以将 RDB 文件复制到远程服务器或者存储为历史数据快照。
• 恢复速度更快 ：相较于 AOF 持久化方式，在数据集较大的情况下，RDB 文件恢复数据的速度通常比 AOF 快，因为它是直接根据数据快照进行恢复的，而不需要逐条执行写命令来恢复数据。

（3）缺点

• 数据安全性较低 ：在最后一次成功生成快照之后，如果 Redis 服务出现故障，那么从最后一次快照生成到故障发生期间的数据更新将全部丢失。例如，如果设置 Redis 每小时保存一次 RDB 快照文件，那么在 Redis 故障时可能会丢失最多一小时的数据。
• 无法记录数据的细粒度变化 ：RDB 持久化只能记录某一时刻的数据快照，无法像 AOF 那样记录每个写操作的具体命令，所以在需要精确恢复到某个特定时间点的数据或者在发生数据错误时无法像 AOF 那样通过回放命令来找到问题所在。

（4） 应用场景

• 对数据安全性要求不高的场景，例如缓存系统，主要关注数据的快速读写性能和恢复速度，而对数据丢失一定的容忍度。
• 在需要进行定期备份的场景中，RDB 文件可以作为一个完整的数据备份，便于存储到外部存储设备或者进行异地备份。
• 当 Redis 实例发生故障需要快速恢复时，可以优先考虑使用 RDB 持久化来快速重建数据集。

2. AOF（Append Only File）持久化机制

（1）原理

AOF 持久化方式会记录每一个写操作命令，并以 Redis 协议的格式追加写入到 AOF 文件（默认文件名为 appendonly.aof）中。当 Redis 重启时，会重新执行 AOF 文件中的命令来恢复数据。

在AOF持久化模式中，appendfsync文件同步策略共有三种模式，分别为always、everysec和no, 以下是这三种模式的说明和对比。

策略	描述	数据安全性	性能影响
always	每个命令都同步	最高(零丢失)	最差
everysec	每秒同步一次	高(最多丢失1秒数据)	中等(推荐)
no	由操作系统控制	低	最小

（2） 优点

• 数据安全性高 ：AOF 持久化提供了三种不同的同步策略，分别是每秒同步（everysec）、每个写操作同步（fsync）和让操作系统控制同步（no）。其中每秒同步在性能和数据安全性之间取得了较好的平衡，即使在服务器故障的情况下，最多只会丢失 1 秒钟的数据；而每个写操作同步则可以保证数据的完全持久化，但会对性能产生一定的影响。
• 适合数据恢复到特定时间点 ：由于 AOF 文件记录的是所有的写操作命令，因此可以通过回放这些命令来精确地恢复到某个特定的时间点，这在进行数据修复或者查找数据错误原因时非常有用。
• AOF 文件的可读性高 ：AOF 文件是以 Redis 命令协议的格式保存的，因此可以方便地查看和编辑文件内容，甚至可以手动修改 AOF 文件来纠正数据错误或者进行数据的二次处理。

（3）优点

• 文件体积较大 ：AOF 文件会记录所有的写操作命令，随着时间的推移和数据的不断更新，AOF 文件可能会变得非常庞大，尤其是在写操作频繁的场景下。不过 Redis 提供了 AOF 重写机制来压缩 AOF 文件的体积，但重写过程也需要消耗一定的系统资源。
• 恢复速度相对较慢 ：相比于 RDB 持久化方式，AOF 恢复数据的速度较慢，因为需要逐条执行 AOF 文件中的命令来重建数据集，这可能会导致 Redis 启动时间变长，尤其是在数据量较大的情况下。

（4）应用场景

• 对数据安全性要求极高的场景，如金融系统、计费系统等，不能容忍数据丢失，即使可能会对性能产生一定的影响。
• 当需要进行数据的细粒度恢复或者需要查看数据的变化历史时，AOF 持久化是一个很好的选择。
• 在需要对 Redis 数据进行审计或者分析时，AOF 文件的可读性可以方便地满足这些需求。

3. 混合持久化机制

（1） 原理

混合持久化是 Redis 4.0 及以后版本引入的一种新的持久化方式，它是将 RDB 和 AOF 的优点结合起来。开启混合持久化后，当 AOF 持久化功能开启时，第一次执行 bgsave 命令会像 rdb 持久化一样将内存中的数据库内容快照以二进制的形式写入到临时的 rdb 文件中，但是之后会像 aof 持久化一样将每个写命令追加写入到 aof 缓冲区中。当 Redis 重启时，会优先加载 AOF 模式下的 RDB 快照文件，然后执行 AOF 缓冲区中的写命令来恢复数据。

（2）优点

• 结合了 RDB 和 AOF 的优势 ：既保留了 RDB 文件的快速恢复特性，又兼顾了 AOF 文件的数据安全性和细粒度恢复能力。
• 优化了性能和数据安全性之间的平衡 ：在保证较高数据安全性的同时，通过利用 RDB 快照的快速恢复特性来提高 Redis 重启时的恢复速度，减少恢复时间。

（3）缺点

• 实现相对复杂 ：混合持久化机制的实现相对较为复杂，需要同时处理 RDB 和 AOF 的相关逻辑和流程，增加了 Redis 的内部复杂性。
• 可能存在兼容性问题 ：在一些特定的场景或者旧版本的 Redis 客户端中，可能会出现兼容性问题，需要进行充分的测试和验证。

（4） 应用场景

• 对于需要兼顾数据恢复速度和数据安全性的场景，混合持久化是一个理想的选择。例如，一些对性能要求较高但同时又不能容忍较多数据丢失的业务系统。
• 可以作为 RDB 和 AOF 持久化的一种替代方案，在不同的业务场景和需求下灵活配置和使用。

Redis 的持久化机制各有特点和适用场景，我们在业务系统应用中可以根据实际的业务需求和性能要求来选择合适的持久化方式，或者采用混合持久化的方式来达到更好的平衡。

三. Redis持久化配置

Redis的持久化机制可以通过配置文件（通常是redis.conf）进行设置。

AOF持久化配置示例

# 是否开启AOF持久化机制，no表示关闭，yes表示开启  
appendonly yes 
# AOF文件名
appendfilename "appendonly.aof"  
 # 同步策略(推荐)
appendfsync everysec       
# 增长100%时触发重写
auto-aof-rewrite-percentage 100  
# AOF文件最小重写大小
auto-aof-rewrite-min-size 64mb   
# 加载截断的AOF文件
aof-load-truncated yes      

RDB持久化配置示例

#RDB持久化自动触发条件
save 900 1
save 300 10
save 60 10000
#bgsave持久化失败，是否停止持久化数据到磁盘，yes 表示停止持久化，no 表示忽略错误继续写文件
stop-writes-on-bgsave-error yes
#rdb文件是否压缩
rdbcompression yes
#写入文件和读取文件时是否开启rdb文件检查，检查是否有无损坏，如果在启动是检查发现损坏，则停止启动。
rdbchecksum yes
#rdb持久化后存放的文件名
dbfilename dump.rdb
#rdb持久化后文件的存放路径
dir ./

Redis常用的配置项说明

1. appendonly：该选项用于开启或关闭持久化功能。当值为"yes"时，开启持久化；为"no"时，关闭持久化。默认情况下，该选项为"no"。
2. appendfilename：AOF持久化文件名。默认值为"appendonly.aof"。你可以根据实际需要修改这个值。
3. appendfsync：控制AOF文件同步到磁盘的策略。可选值包括"always"（每个写命令都立即同步）、"everysec"（每秒同步一次）和"no"（由操作系统决定何时同步）。默认值为"always"。
4. save ：用于配置RDB持久化。该选项可以设置多个保存点，每个保存点由一个时间间隔和相应的数据修改次数组成。当指定的时间间隔内数据修改次数达到指定次数时，Redis将生成一个RDB文件。示例：save 10 100。表示在10秒内如果数据被修改超过100次，就生成RDB文件。
5. rdbcompression：RDB文件是否采用压缩方式存储。当值为"yes"时，启用压缩；为"no"时，禁用压缩。默认值为"yes"。
6. rdbchecksum：RDB文件是否进行校验和。当值为"yes"时，进行校验和；为"no"时，不进行校验和。默认值为"yes"。
7. dbfilename : RDB持久化文件名。默认值为"dump.rdb"，可以根据实际需要自行修改。
   这些配置选项可以在redis.conf文件中进行设置，以满足你的实际需求。根据你的应用场景和性能需求，你可能需要调整这些选项以获得更好的持久化性能和数据安全性。