RDB(快照)持久化
保存某个时间点的全量数据快照
- SAVE:阻塞redis的服务器进程,直到RDB文件被创建完毕
- BGSAVE:Fork(创建进程,实现了Copy-On-Write)出一个子进程来创建RDB文件,不阻塞服务器进程
自动化触发RDB持久化方式
- 根据redis.conf配置里的SAVE m n 定时触发(BGSAVE方式)
- 主从复制时,主节点自动触发
- 执行Debug Reload
- 执行Shutdown且没有开启AOF持久化
可用lastsave查看上一次持久化时间
AOF(Append-Only-File)持久化:
保存写状态
- 记录下除了查询以外的所有变成数据库操作的指令
- 以append的形式追加到AOF文件中(增量)
日志重写解决AOF文件不断增大的问题,原理如下:
- 调用fork(),创建一个子进程
- 子进程把新的AOF文件写到一个临时文件里,不依赖原来的AOF文件(把当前内存的数据生成一份命令,不需要读取老的文件进行分析或是合并)
- 主进程持续将新的变动同时写到内存和原来的AOF文件里(即使重写失败也能保证数据的安全)
- 主进程获取子进程重写AOF的完成信号,往新的AOF同步增量变动
- 使用新的AOF文件替换掉旧的AOF文件
Redis数据的恢复:
RDB和AOF共存的情况下的恢复流程:
- 数据在恢复的过程中redis会首先判断是否存在AOF文件,如果存的情况下,会直接加载AOF文件,随后启动
- 如果不存在AOF文件则会接着进行判断是否存在RDB,如果存在的情况下,加载RDB,随后启动
- 什么都不存在,就直接启动喽
RDB和AOF的优缺点:
- RDB优点:全量数据快照,文件小,恢复快
- RDB缺点:无法保存最近一个快照之后的数据
- AOF优点:可读性高,适合保存增量数据,数据不易丢失
- AOF缺点:文件体积大,恢复时间长
RDB-AOF混合持久化方式
BGSAVE(会耗费较长时间,不够实时,在停机的时候会导致大量的丢失数据),做镜像全量持久化,AOF做增量持久化
先写一份全量数据到AOF文件中,再追加增量数据,全量数据以redis命令方式写入。这样既可以提高重写和恢复速度,也可以减少文件大小,同时还保证数据的完整性。