Redis持久化
- Redis RDB持久化
- 触发机制
- 自动触发RBD持久
- Copy-on-Write
- Redis AOF持久化
- 日志重写如何解决AOF文件大小不断增大的问题?
- RDB和AOF混合持久化
- 解决办法
Redis支持RBD和AOF两种持久机制,持久化功能有效地避免了因进程退出造成的数据丢失问题,当下次重启时利用之前持久化的文件可实现数据恢复。
Redis RDB持久化
RDB持久化是把当前进程数据生成快照保存到硬盘的过程。
缺点:
- 内存数据的全量同步,数据量大会由于I/O严重影响性能
- 可能会因为Redis挂掉而丢失从当前最近一次快照期间的数据
触发机制
- save命令: 阻塞当前Redis服务器,知道RDB过程完成为止,对于内存比较大的实例会造成长时间阻塞,线上不建议使用
- bgsave命令: Redis进程执行fork操作创建子进程,RDB持久化过程由子进程负责,完成后自动结束。阻塞只发生在fork阶段,一般时间很短。
自动触发RBD持久
- -使用save相关配置:如“save m n”。表示m秒内数据集存在n次修改时自动触发bgsave。
- 如果从节点执行全量复制操作,主节点自动执行bgsave生成RBD文件并发送给从节点。
- 执行debug reload命令重新加载Redis时,也会自动触发save操作
- 默认情况下执行shutdown命令时,如果没有开启AOF持久化功能则自动执行bgsave
Copy-on-Write
子进程期间使用copy-on-write机制与父进程共享内存,避免内存消耗翻倍。如果有多个调用者同时要求相同的资源(如内存或磁盘上的存储),他们会共同获取相同的指针指向相同的资源,知道某个调用者试图修改资源时,系统才会真正复制专份给该调用者,而其他调用者所见到的最初资源仍然保持不变。
Redis AOF持久化
AOF(append only file) 持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性。目前已是Redis持久化的主流方式。
日志重写如何解决AOF文件大小不断增大的问题?
- 调用fork,创建一个子进程
- 子进程把新的数据写进一个临时的AOF文件,不依赖原来的AOF文件
- 子进程持续将新的变动同时写到AOF和内存中。即使Redis意外故障也会使得数据丢失
- 主进程获取子进程重写AOF完成信号,往新AOF同步增量变动
- 使用新的AOF文件替换旧的AOF文件
RDB和AOF混合持久化
由于RDB和AOF 都各有优缺点,为了性能总体提升,可以采用RDB和AOF混合持久化。
- RDB
优点:全量数据快照,文件小,恢复快。
缺点:无法保存最近一次快照之后的数据 - AOF
优点:可读性高,适合保存增量数据,数据不易丢失
缺点:文件体积大,恢复慢
解决办法
BGSAVE做镜像全量持久化,AOF做增量持久化