## RDB

> 通过快照来创建所有数据在某个时间节点的快照，是默认启用的持久化机制

1. RDB 创建快照会阻塞主线程吗

使用 `save` 时同步保存会阻塞，使用 `bgsave` 会 fork 出一个子线程不会阻塞

## AOF

> 日志文件追加，每次执行完都会间命令写入到 AOF 缓冲区中，再写入 AOF 文件中，最后同步到硬盘

1. 工作流程

- **命令追加**，将所有写入的命令追加到 AOF 缓冲区
- **文件写入**，将 AOF 缓冲区的数据写入到 AOF 文件中
- **文件同步**，AOF 根据对应持久化方式（fsync 策略）向硬盘做同步操作
- **文件重写**，当 AOF 文件越来越大，达到一定的体积后会修 AOF 文件进行重写，压缩文件
- **重启加载**，当 redis 重启时，可以加载 AOF 文件恢复数据

2. AOF 持久化方式

- `appendfsync always`：即时同步，主线程写入操作后立即使用 fsync 同步文件再返回
- `appendfsync second`：每秒同步，主线程 write 写入后立即返回，后台每秒调用 fsync 同步到硬盘
- `appendfsync no`：由操作系统决定何时同步，主线程写入后立即返回

3. AOF 为什么在执行完命令之后记录日志

- 避免对命令检查带来的开销
- 执行完之后不会阻塞当前命令
- 可能会导致数据丢失
- 可能阻塞后续命令执行

4. AOF 重写

当 AOF 文件过大时，redis 在后台重写 AOF 产生一个新的 AOF 文件，会对文件进行压缩，
重写期间会维护一个 AOF 重写缓冲区，期间所有写入命令会记录到这里，当重写完成后会追加到新的 AOF 文件中

默认重写 64MB，可在配置修改

5. AOF 校验机制

启动时对 AOF 文件进行校验，避免文件损坏和丢失，提升数据可靠性

6. 4.0 对持久化机制做了什么优化

混合持久化，AOF 重写时把 RDB 内容添加到 AOF 问文件开头，从而快随加载同时避免丢失过多数据，缺点时可读性较差

7. 如何选择

如果对于丢失数据没太大影响，使用 RDB，安全性要求较高，使用AOF