51 lines
2.1 KiB
Markdown
51 lines
2.1 KiB
Markdown
## 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 |