【Redis —— 05 RDB & AOF】

Redis 提供了两种持久化方式：RDB（Redis Database）和 AOF（Append-Only File）。这两种方式各有优缺点，可以根据具体需求进行选择和配置。

RDB 持久化

工作原理

RDB 通过创建数据库的快照来保存数据到磁盘中。快照是指在某个时刻将所有数据保存到一个二进制文件中，文件的默认名称是 dump.rdb。

配置选项

# save：配置 RDB 持久化的触发条件。可以设置多个条件
save 900 1   # 900秒内至少有1次写操作
save 300 10  # 300秒内至少有10次写操作
save 60 10000 # 60秒内至少有10000次写操作

# stop-writes-on-bgsave-error：在后台保存失败时是否停止写操作。默认值为 yes
stop-writes-on-bgsave-error yes

# rdbcompression：是否压缩 RDB 文件。默认值为 yes
rdbcompression yes

# rdbchecksum：是否在 RDB 文件中进行校验和。默认值为 yes
rdbchecksum yes

# dbfilename：RDB 文件的名称。默认值为 dump.rdb
dbfilename dump.rdb

# dir：RDB 文件的存储路径
dir /var/lib/redis

优点

1. 性能：RDB 的持久化对 Redis 性能的影响较小，因为 Redis 在创建快照时会 fork 一个子进程，这样主进程可以继续处理客户端请求。
2. 文件体积小：RDB 文件通常比 AOF 文件小，适合进行备份。
3. 恢复速度快：RDB 文件是紧凑的二进制文件，可以快速加载到内存中。

缺点

1. 数据丢失风险：如果 Redis 在快照之间崩溃，所有自上次快照以来的写入操作都会丢失。
2. 耗费资源：生成快照可能会消耗大量 CPU 和内存资源，特别是数据量大的情况下。

AOF 持久化

工作原理

AOF 通过将每个写操作记录到日志文件中来持久化数据。AOF 文件的默认名称是 appendonly.aof。

配置选项

# appendonly：是否开启 AOF 持久化。默认值为 no
appendonly yes

# appendfilename：AOF 文件的名称。默认值为 appendonly.aof
appendfilename "appendonly.aof"

# appendfsync：AOF 文件的同步策略。可选值有：
#      always：每次写操作后立即同步到磁盘，性能最差但最安全。
#      everysec：每秒同步一次，折中方案，默认值。
#      no：不主动同步，由操作系统决定何时写入磁盘，性能最好但最不安全。
appendfsync everysec

# no-appendfsync-on-rewrite：在 AOF 重写期间是否禁止同步。默认值为 no
no-appendfsync-on-rewrite no

# auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size：配置自动重写 AOF 文件的条件。
# 默认情况下，当 AOF 文件的大小比上次重写后的大小大 100% 时，触发自动重写。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

AOF 文件重写的原理

AOF 文件重写并不是简单地压缩现有的 AOF 文件，而是生成一个新的、更加紧凑的 AOF 文件。重写过程中，Redis 会创建一个新的 AOF 文件，只包含当前数据库状态的最少命令集，从而达到优化文件大小的目的。

重写过程

1. 开始重写：Redis 通过 BGREWRITEAOF 命令触发重写过程。这个过程会在后台进行，不会阻塞主线程。
2. 创建子进程：Redis 会 fork 一个子进程，用于执行重写操作。子进程会扫描当前的数据库状态，将其转换为一系列最小化的写操作，并写入到一个新的 AOF 文件中。
3. 处理新命令：在重写过程中，主进程会继续处理新的写命令，并将这些新命令追加到一个内存缓冲区中。这样可以确保新命令不会丢失。
4. 合并新命令：当子进程完成重写并生成新的 AOF 文件后，主进程会将内存缓冲区中的新命令追加到新的 AOF 文件中。
5. 替换旧文件：最后，Redis 会将旧的 AOF 文件替换为新的 AOF 文件，并删除旧文件。整个过程对客户端是透明的，不会中断服务。

优点

1. 数据安全性高：AOF 可以配置成非常安全，通常只会丢失最近一秒钟的数据。
2. 可读性好：AOF 文件是日志文件，可以通过文本编辑器查看，便于调试。
3. 重写机制：Redis 可以对 AOF 文件进行后台重写，减少文件大小。

缺点

1. 文件体积大：AOF 文件通常比 RDB 文件大，因为它记录了每个写操作。
2. 恢复速度慢：恢复 AOF 文件需要重新执行所有写操作，速度比加载 RDB 文件慢。
3. 性能影响大：AOF 会对性能有一定影响，特别是设置为 appendfsync always 时。

选择和组合使用

• 只使用 RDB：适用于对数据丢失不敏感，且需要高性能的场景。
• 只使用 AOF：适用于对数据安全性要求高的场景，但需要注意性能和文件大小问题。
• 同时使用 RDB 和 AOF：推荐的配置，既可以利用 RDB 的快速恢复，又能保证 AOF 的数据安全性。Redis 会优先使用 AOF 文件恢复数据，因为 AOF 数据更完整。