2.1 KiB
2.1 KiB
RDB
通过快照来创建所有数据在某个时间节点的快照,是默认启用的持久化机制
- RDB 创建快照会阻塞主线程吗
使用 save 时同步保存会阻塞,使用 bgsave 会 fork 出一个子线程不会阻塞
AOF
日志文件追加,每次执行完都会间命令写入到 AOF 缓冲区中,再写入 AOF 文件中,最后同步到硬盘
- 工作流程
- 命令追加,将所有写入的命令追加到 AOF 缓冲区
- 文件写入,将 AOF 缓冲区的数据写入到 AOF 文件中
- 文件同步,AOF 根据对应持久化方式(fsync 策略)向硬盘做同步操作
- 文件重写,当 AOF 文件越来越大,达到一定的体积后会修 AOF 文件进行重写,压缩文件
- 重启加载,当 redis 重启时,可以加载 AOF 文件恢复数据
- AOF 持久化方式
appendfsync always:即时同步,主线程写入操作后立即使用 fsync 同步文件再返回appendfsync second:每秒同步,主线程 write 写入后立即返回,后台每秒调用 fsync 同步到硬盘appendfsync no:由操作系统决定何时同步,主线程写入后立即返回
- AOF 为什么在执行完命令之后记录日志
- 避免对命令检查带来的开销
- 执行完之后不会阻塞当前命令
- 可能会导致数据丢失
- 可能阻塞后续命令执行
- AOF 重写
当 AOF 文件过大时,redis 在后台重写 AOF 产生一个新的 AOF 文件,会对文件进行压缩, 重写期间会维护一个 AOF 重写缓冲区,期间所有写入命令会记录到这里,当重写完成后会追加到新的 AOF 文件中
默认重写 64MB,可在配置修改
- AOF 校验机制
启动时对 AOF 文件进行校验,避免文件损坏和丢失,提升数据可靠性
- 4.0 对持久化机制做了什么优化
混合持久化,AOF 重写时把 RDB 内容添加到 AOF 问文件开头,从而快随加载同时避免丢失过多数据,缺点时可读性较差
- 如何选择
如果对于丢失数据没太大影响,使用 RDB,安全性要求较高,使用AOF