RDB持久化原理
自动触发
save 900 1
采用时间策略, 900s后如果有一条写入命令就触发一次快照
手动触发
- save: 阻塞redis服务器,直到持久化完成
- bgsave: fork一个子进程,由子进程负责持久化过程,因此阻塞只会发生在fork子进程的时候
AOF持久化原理
appendfsync同步模式
- always 把每个写入命令都立即同步到aof,很慢,很安全
- everysec 每秒同步一次
- no 交给操作系统处理,非常快,但是不安全
AOF整体流程
- 命令的实时写入
- 对AOF文件进行重写
graph TD
A[命令写入] --> B(追加到aof_buf缓冲区)
B --> C(通过时间事件调用flushAppendOnlyFile函数同步到aof磁盘)
Redis持久化恢复过程
先检测AOF进行恢复,如果没有才检测RDB进行恢复
RDB的优缺点
优点:
- RDB最大限度的提高了redis的性能,父进程不需要参与磁盘的I/O
- 与AOF相比,RDB允许进行大数据集更快重启
缺点:
- 如果需要在redis停止工作的时候将数据丢失的可能性降至最低,RDB并不好
- RDB经常需要fork才能使用子进程持久存储在磁盘上,如果数据集很大,fork很可能会非常耗时间
AOF的优缺点
优点:
- 数据更加安全
- 当redis太大时,Redis能够在后台自动重写AOF
AOF以易于理解和解析的格式一个接一个的包括所有操作的日志
缺点:
- AOF文件通常比统一数据集的等效RDB文件大
根据确切的fsync策略,AOF可能比RDB慢