redis的持久化
redis有2种持久化方法
1.RDB
手动触发为bgsave命令
bgsave命令的运作流程
1)执行bgsave命令,Redis父进程判断当前是否存在正在执行的子进程,如RDB/AOF子进程,如果存在bgsave命令直接返回。
2)父进程执行fork操作创建子进程,fork操作过程中父进程会阻塞。
3)父进程fork完成后,可以继续响应其他命令。
4)子进程创建RDB文件,根据父进程内存生成临时快照文件,完成后对原有文件进行原子替换。
5)进程发送信号给父进程表示完成
RDB的优点/缺点
-
优点
Redis加载RDB恢复数据远远快于AOF的方式 -
缺点
RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程,属于重量级操作,频繁执行成本过高。
2.AOF
以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的。
AOF的主要作用是解决了数据持久化的实时性。
AOF工作流程
1)所有的写入命令会追加到aof_buf(缓冲区)中。
AOF为什么把命令追加到aof_buf中?Redis使用单线程响应命令,如果每次写AOF文件命令都直接追加到硬盘,那么性能完全取决于当前硬盘负载。
2)AOF缓冲区根据对应的策略向硬盘做同步操作
同步文件策略
-
always
每次写入都要同步AOF文件,在一般的SATA硬盘上,Redis只能支持大约几百TPS写入,显然跟Redis高性能特性背道而驰,不建议配置。 -
everysec
是建议的同步策略,也是默认配置,做到兼顾性能和数据安全性。理论上只有在系统突然宕机的情况下丢失1秒的数据。 -
no
由于操作系统每次同步AOF文件的周期不可控,而且会加大每次同步硬盘的数据量,虽然提升了性能,但数据安全性无法保证。
3)AOF文件重写
随着命令不断写入AOF,文件会越来越大,为了解决这个问题,Redis引入AOF重写机制压缩文件体积。
4)重启加载
AOF和RDB文件都可以用于服务器重启时的数据恢复。下图表示Redis持久化文件加载流程