【学习笔记】Redis-AOF日志重写的机制
目录
- 前言
- 1. 触发机制
- 2. 子进程执行
- 3. 写入与同步
- 4. 安全保障
- 5. 潜在问题与优化
前言
AOF（Append Only File）日志重写是Redis中一种优化持久化文件大小和提高数据恢复效率的机制。以下是AOF日志重写的具体机制和步骤：
1. 触发机制
AOF重写可以通过手动触发或自动配置触发：
- 手动触发：通过执行
BGREWRITEAOF命令来启动重写过程。 - 自动触发：Redis配置文件（redis.conf）中可以通过
auto-aof-rewrite-percentage和auto-aof-rewrite-min-size来设置，当AOF文件增长到一定比例或超过最小尺寸时自动触发重写。
2. 子进程执行
- 当
BGREWRITEAOF命令被执行时，Redis会通过fork操作创建一个子进程。这个过程几乎是瞬时的，因为操作系统使用了写时复制（Copy-On-Write）技术。 - 父进程继续处理客户端的命令请求，新接收的命令会被正常追加到现有的AOF文件中。
- 子进程则开始遍历内存中的数据结构，将当前数据库状态转换成一系列重建数据库所需的写命令序列，写入到一个新的临时AOF文件中。
3. 写入与同步
- 子进程在构建新的AOF文件时，会尽可能地优化命令序列，比如使用多条命令的合并命令（如
SET多个键值对）来减少文件大小。 - 一旦重写完成，子进程会向父进程发送一个信号，并提供新AOF文件的路径。
- 父进程收到信号后，会执行以下操作：
- 使用新生成的AOF文件替换老的AOF文件。
- 从这一刻起，新的写操作直接写入到新的AOF文件中。
4. 安全保障
- 在重写期间，如果发生故障（如服务器崩溃），Redis能够通过老的AOF文件保证数据的完整性，因为新的AOF文件只有在完全替换老文件后才开始使用。
- Redis还提供了
aof-use-rdb-preamble配置选项，允许在AOF文件的开头写入RDB格式的快照，进一步加快了故障恢复速度。
5. 潜在问题与优化
- 磁盘I/O压力：AOF重写和常规的AOF追加操作可能对磁盘造成较大压力，尤其是在高负载环境下。
- 阻塞风险：尽管AOF重写由子进程完成，理论上不会阻塞主进程，但如果磁盘I/O饱和，可能会间接影响到主进程处理命令的速度。
