一、关于Redis 持久化
1.1 简介
Redis 是一个内存数据库，意味着它主要将数据存储在内存中，从而能够提供极高的性能。然而，作为内存数据库，Redis 默认情况下的数据不会永久保存。为了确保数据在重启或故障后能够恢复，Redis 提供了几种 持久化机制。这些机制允许 Redis 将内存中的数据保存到硬盘上，从而实现数据持久化。
Redis 提供了两种主要的持久化方式：RDB（Redis 数据库快照） 和 AOF（Append-Only File）日志。除此之外，Redis 还提供了 混合持久化 机制，结合了 RDB 和 AOF 的优点。
1.2 发展
Redis 的持久化机制经历了多个版本的改进与演化，随着需求的变化，Redis 提供了不同的持久化方案来满足各种应用场景。以下是 Redis 持久化发展历程的简要概述：
- 早期（Redis 1.x）
- 在 Redis 1.x 版本，持久化机制的设计就已经开始出现，并且初步支持了 RDB（Redis 数据库快照） 机制。此时，RDB 是 Redis 唯一的持久化方式。
- RDB（快照） ：每隔一段时间，Redis 会将内存中的数据写入到磁盘生成一个二进制文件（
dump.rdb），通过这种方式来保证数据在重启后能够恢复。 - 该版本的持久化机制设计较为简单，主要是为了提供对数据丢失的容忍以及重启后的数据恢复能力。
- Redis 2.0 - 引入 AOF（追加文件）
AOF（Append-Only File） ：在 Redis 2.0 版本中，新增了 AOF 持久化，这为 Redis 提供了另一种持久化策略。与 RDB 快照不同，AOF 会记录 Redis 执行的所有写操作，并将这些操作以日志的形式追加到文件中（
appendonly.aof）。在 Redis 重启时，可以通过重放 AOF 文件中的命令恢复数据。- AOF 提供了比 RDB 更高的数据安全性，因为它记录了每个操作，理论上可以做到几乎没有数据丢失。
- 但是，由于每个写操作都需要同步到磁盘，AOF 的性能开销相对较大，尤其是在高频率写入的情况下。
- Redis 2.4 - AOF 重写机制
- 在 Redis 2.4 版本中，为了减少 AOF 文件随着时间推移而变得越来越大的问题，引入了 AOF 重写机制（AOF Rewrite） 。
- AOF 重写机制通过创建一个新的 AOF 文件，重写当前数据库状态下的最小化写操作，将文件缩减到一个更小的大小。这一机制使得 AOF 文件不会无限增长，有助于节省磁盘空间。
- 通过定期重写 AOF 文件，Redis 在性能和磁盘空间使用之间找到了一个较好的平衡。
- Redis 3.0 - 引入 RDB 和 AOF 混合持久化
Redis 3.0 在原有的 RDB 和 AOF 两种持久化机制基础上，提出了 RDB + AOF 混合持久化 方案。
- 混合持久化模式将 RDB 和 AOF 的优点结合起来：在 Redis 重启时，首先使用 RDB 文件进行快速恢复，然后再用 AOF 文件来完成更高精度的恢复。这样可以在启动时获得更好的性能，同时减少 AOF 文件的恢复时间。
- 混合持久化机制通过将 AOF 写操作存储在 RDB 快照文件之后，减少了 AOF 文件的大小，并提高了数据恢复的速度。
- Redis 4.0 - AOF 重写性能优化
- 在 Redis 4.0 版本中，AOF 重写机制进行了进一步的优化，尤其是在内存消耗和文件重写的效率上做了改进。
- Redis 4.0 引入了 AOF 持久化重写时的后台线程，即 AOF 重写不再阻塞主线程，而是通过一个后台线程异步地进行，从而避免了 AOF 重写过程中的性能瓶颈。
- 此外，Redis 4.0 增强了对 AOF 文件在大规模数据时的处理能力，使得 AOF 持久化更加高效。
- Redis 5.0 - AOF 日志的优化和压缩
- Redis 5.0 进一步对 AOF 持久化机制进行了优化，增强了 AOF 文件的压缩和优化。通过对 AOF 文件中的重复操作进行压缩，减少了磁盘的使用空间，提升了 AOF 机制的性能。
- Redis 5.0 中还对持久化的配置进行了一些细化，比如优化了 AOF 文件的重写触发机制，避免了重写过程中因不必要的操作而造成性能的影响。
- Redis 6.0 - 持久化机制的改进和安全性增强
- Redis 6.0 版本对持久化机制做了些许优化，尤其是对 AOF 和 RDB 文件在高负载下的表现进行了改进，提升了 Redis 在大规模部署时的稳定性。
- 此版本还引入了更多的安全性特性，比如 更强的加密 支持和对客户端连接的限制，虽然这些主要是针对安全性，但间接地影响了 Redis 的持久化性能。
- 同时，Redis 6.0 提供了更多灵活的配置选项，允许更精细地控制持久化机制的行为，以适应不同的生产环境需求。
- Redis 7.0 - 更进一步的持久化优化
- Redis 7.0 引入了 更智能的 AOF 重写机制，进一步优化了 Redis 启动和恢复的速度。
- 在 Redis 7 中，持久化机制更加灵活，通过配置
appendfsync（AOF 文件同步策略）和save（RDB 快照保存策略），用户可以精确控制持久化行为，从而在性能和数据一致性之间找到平衡。 - Redis 7.0 对 RDB 文件和 AOF 文件的合并操作进行了改进，以便在某些情况下减少系统资源的消耗，并提高数据恢复效率。
二、RDB 持久化（快照）
2.1 简介
RDB（Redis Database）持久化通过 定期创建数据快照 来保存数据。RDB 会将 Redis 内存中的数据保存到一个二进制文件（默认为 dump.rdb）中。
Redis 默认启用了 RDB 快照 持久化，而 AOF 持久化 默认是关闭的
2.2 工作原理
- Redis 会在特定的时间间隔内，自动将内存中的数据快照保存到磁盘上（即 RDB 文件）。
- RDB 是一种 时间点快照，这意味着 Redis 会在某个时间点将内存中的数据全部写入文件。如果在快照期间发生了数据变化，那么这些变化将不会出现在该快照中。
- 当 Redis 执行
BGSAVE 命令或者根据save 配置自动执行时，它会通过fork() 系统调用创建一个子进程，子进程会将当前内存中的所有数据（整个数据库的内容）写入一个临时的 RDB 文件。 - 快照的写入是一次性操作，不会中途停止，也没有增量更新。
- 快照完成后，新的 RDB 文件会替换原先的文件（通常是
dump.rdb）。
2.3 配置方法
可以通过
redis.conf 文件中的配置来设置 RDB 快照的生成条件。例如，设置在特定时间内执行多少次写操作后进行快照：save 900 1 # 900秒内如果至少发生1次写操作，则生成快照 save 300 10 # 300秒内如果至少发生10次写操作，则生成快照 save 60 10000 # 60秒内如果至少发生10000次写操作，则生成快照
这些条件是 “或” 的关系，也就是说，只要 任意一个条件满足，Redis 就会执行快照操作。因此，只要有任意一组条件被触发，Redis 就会创建 RDB 快照文件。
windows redis版本，redis.windows.conf文件配置
2.4 优点
- 性能高效：RDB 持久化是基于快照的方式，生成快照时对 Redis 的性能影响相对较小。
- 恢复速度快：当 Redis 重启时，RDB 文件加载速度较快，可以迅速恢复数据。
- 节省磁盘空间：由于是定期生成快照，因此 RDB 文件通常比 AOF 文件小。
2.5 缺点
- 数据丢失风险：由于 RDB 是基于快照的，如果在快照生成和下一次快照之间发生故障，则该段时间内的数据将丢失。
- 不够灵活：无法像 AOF 那样记录每一条命令，灵活性较差。
2.6 使用场景
- 适用于对数据丢失要求不高的场景，或者数据本身容易重建的应用。
- 在大多数情况下，RDB 适合用来进行数据备份。
三、AOF 持久化（Append-Only File）
3.1 简介
AOF（Append-Only File）是 Redis 的另一种持久化机制，它通过记录所有写操作的日志来确保数据持久性。每次对 Redis 执行写操作时，都会将该操作追加到 AOF 文件中。AOF 文件实际上是 Redis 执行命令的一个日志，重启 Redis 时，Redis 会重新执行这些命令来恢复数据。
文件名：appendonly.aof，如果没有更改过配置文件的 dir 配置，默认会在 Redis 的当前工作目录下生成 AOF 文件。
3.2 工作原理
- Redis 将每一个写操作（如
SET、INCR 等）追加到 AOF 文件中，AOF 文件会记录每个写命令。 - 在 Redis 重启时，会重新执行 AOF 文件中的命令，恢复数据。
3.3 配置方法
可以通过
redis.conf 文件中的appendonly 配置项开启 AOF 持久化：appendonly yes appendfilename "appendonly.aof"AOF 同步策略：Redis 提供了三种 AOF 同步策略，控制写命令同步到 AOF 文件的方式：
appendfsync always：每个写命令都会同步到 AOF 文件（最安全，但性能最差）。appendfsync everysec：每秒同步一次（既保证了数据安全，又提供了较好的性能，推荐使用）。appendfsync no：Redis 依赖操作系统来同步 AOF 文件（性能最好，但数据安全性最差）。
3.4 优点
- 数据安全性高：AOF 持久化记录了每个写命令，即使 Redis 崩溃，AOF 文件可以保证数据的恢复。
- 精确恢复：由于记录的是每个写命令，AOF 可以恢复到非常接近崩溃时的状态。
3.5 缺点
- 性能开销较大：每次写命令都需要记录到 AOF 文件，频繁的磁盘写入会影响性能。
- AOF 文件可能较大：由于记录了每一条写操作，AOF 文件通常比 RDB 文件大，特别是在写操作频繁的情况下。
3.6 使用场景
- 适用于对数据安全性要求较高的场景，如金融、交易系统等。
四、混合持久化（RDB + AOF）
4.1 简介
Redis 4.0 引入了 混合持久化（Hybrid Persistence）功能，将 RDB 和 AOF 结合起来，结合了两者的优点。混合持久化将 RDB 快照的内容和 AOF 操作日志结合保存。
备注：Redis Windows 版本（无论是官方的还是第三方移植的版本）并不支持混合持久化功能。（Redis 最初是为了 Linux/Unix 系统设计的，因此官方并未提供直接支持 Windows 的原生版本。Windows 上的 Redis 实际上是通过 Microsoft 的开源项目 MicrosoftArchive/redis 来移植的，或者有社区的其他移植版本。）
4.2 工作原理
- 在混合持久化模式下，Redis 会在生成 RDB 快照时，将 RDB 快照头和 AOF 日志结合成一个新的 AOF 文件。这样既保证了数据在恢复时的精确性，又降低了 AOF 文件的大小。
4.3 优点
- 恢复速度快：因为它结合了 RDB 的快速恢复能力和 AOF 的精确恢复能力。
- 节省磁盘空间：相比纯 AOF，混合持久化生成的文件更小。
- 高性能：相对于纯 AOF 持久化，混合持久化对性能的影响较小。
4.4 配置方法
要启用混合持久化，您需要在 redis.conf 配置文件中做如下设置：
启用 AOF 持久化： 确保
appendonly 配置项设置为yes，表示启用 AOF 持久化。appendonly yes启用混合持久化： 在 Redis 4.0 及以上版本，混合持久化是默认启用的，但您可以通过设置以下选项来进行配置：
aof-use-rdb-preamble yes这个配置项的作用是启用 AOF 文件中的 RDB 前缀（即在 AOF 文件开头部分存储 RDB 快照）。如果设置为
no，则 Redis 会使用传统的 AOF 文件格式，不会混合 RDB 快照。RDB 和 AOF 配置： 如果您已经启用了 AOF 持久化，您可以继续使用常规的 AOF 配置项来调整 AOF 文件的行为（如
appendfsync 和auto-aof-rewrite 等）。
完整配置示例：
# 启用 AOF 持久化
appendonly yes
# 启用混合持久化
aof-use-rdb-preamble yes
# AOF 文件同步策略（根据需要选择）
appendfsync everysec
# AOF 文件的重写策略
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# 定期创建 RDB 快照的配置（如果需要）
save 900 1 # 900秒（15分钟）内至少有1次写操作
save 300 10 # 300秒（5分钟）内至少有10次写操作
save 60 10000 # 60秒内至少有10000次写操作
4.5 使用场景
- 高频写入与持久化要求高的场景：混合持久化减少了 AOF 写入的性能瓶颈，同时保证数据持久化。
- 快速恢复场景：混合持久化利用 RDB 快速恢复数据，再通过 AOF 恢复增量更新，减少恢复时间。
- 磁盘 I/O 和内存占用平衡的场景：结合 RDB 的定期快照和 AOF 的增量更新，避免 AOF 文件过大，优化磁盘空间使用。
- 高可用性和数据安全性需求：通过结合 RDB 和 AOF，减少数据丢失的风险，并保证数据快速恢复。
- 低延迟要求的系统：混合持久化减少了 AOF 文件的写入，降低了磁盘延迟，适用于低延迟的应用场景。
五、持久化选择与配置
在实际应用中，如何选择持久化方式取决于对 性能 和 数据安全性 的不同需求：
- 如果 数据安全性要求较高，可以选择 AOF 持久化或混合持久化。
- 如果 对性能要求较高，且可以容忍少量数据丢失（例如一分钟内的数据），则可以使用 RDB 持久化。
- 对于一些 备份需求，可以使用 RDB 配合 AOF，获得两者的优势。
Redis 提供了两种主要的持久化机制：RDB 和 AOF，每种机制有各自的优缺点。RDB 更注重性能，适合做定期备份，但可能会丢失最近的几分钟数据；AOF 更注重数据的完整性，适合对数据丢失敏感的应用，但会带来一定的性能开销。混合持久化结合了 RDB 和 AOF 的优势，可以提供更快的恢复速度和更小的文件大小。根据具体的业务需求，可以选择合适的持久化策略。
