Redis持久化策略剖析
Posted 白龙码~
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Redis持久化策略剖析相关的知识,希望对你有一定的参考价值。
文章目录
持久化策略
Redis提供了RDB持久化、AOF持久化、RDB-AOF混合持久化三种持久化策略。
1、RDB持久化
RDB持久化是Redis默认持久化方式,可以通过
SAVE或BGSAVE
命令触发,也可以通过配置选项,让服务器在保存条件满足时执行BGSAVE
命令,最终生成一个二进制RDB文件,文件中保存了数据库中的所有键值对。
SAVE
命令会阻塞当前进程,直到RDB文件创建完毕,在此期间服务器无法响应请求。BGSAVE
命令会fork
一个子进程,让子进程创建RDB文件,父进程继续响应请求。在BGSAVE执行期间,客户端发送的SAVE和BGSAVE请求都会被服务端拒绝。
RDB持久化的优缺点分析:
- 优点:RDB文件是一个经压缩的二进制文件,体积小,使用该文件恢复数据的速度非常快。
- 缺点:
BGSAVE
每次运行都要执行fork操作创建子进程,属于重量级操作,不宜频繁执行,无法做到实时持久化,因此可能会丢失大量数据。
2、AOF持久化
AOF,即Append Only File,文件中保存了服务器执行的所有写命令。
AOF持久化的实现分为三个步骤:命令追加、文件写入和文件同步。
- 命令追加
AOF功能开启时,服务器在执行完写命令后会将其追加到一个名为aof_buf
的缓冲区末尾。
- 命令写入
Redis的服务进程就是一个循环,每当执行到文件事件处理函数时,就会根据配置文件的appendfsync
选项判断当前是否需要将aof_buf
的内容写入到AOF文件中,判断方法如下:
- 文件同步
即调用系统函数fsync()或fdatasync()
,强制将文件缓冲区的内容刷新到磁盘。
AOF重写原理:
随着命令越来越多,AOF文件也会逐渐膨胀。为此,Redis提供了
BGREWRITEAOF命令
执行AOF文件重写的功能。
当执行BGREWRITEAOF
时,Redis服务端会创建一个子进程,该进程负责直接读取数据库中的键值对,生成对应的命令,后期恢复时可以通过该命令生成一个相同的键值对,达到恢复整个数据库的目的。
在子进程重写AOF时,会创建一个AOF重写缓冲区,如果有的键值对
在重写期间被修改,此时服务器就会将这个修改命令写入到重写缓冲区中,方便子进程实时修改重写的AOF文件。
AOF持久化的优缺点分析:
-
优点:与RDB持久化可能丢失大量的数据相比,AOF持久化的安全性要高很多。通过使用
everysec
选项,用户可以将数据丢失的时间窗口限制在1秒之内。 -
缺点:
- AOF是文本文件,它的体积要比二进制格式的RDB文件大很多。
- AOF需要通过执行AOF文件中的命令来恢复数据库,其恢复速度比RDB慢很多。
- 每个写命令会伴随着Redis服务器将命令写入缓冲区的操作,因此会降低部分性能。
注:AOF采用文本文件,具有可读性,且避免了二次处理的开销。
3、RDB-AOF混合持久化
- 在执行重写AOF文件时,不再根据键值对生成命令,而是生成RDB文件格式的压缩二进制数据。
- 对于执行重写期间的写命令,以文本格式追加到AOF文件末尾,即压缩二进制数据的后面。
通过使用RDB-AOF混合持久化,用户可以同时获得RDB持久化和AOF持久化的优点,服务器既可以通过AOF文件包含的RDB数据来实现快速的数据恢复操作,又可以通过AOF文件包含的AOF数据来将丢失数据的时间窗口限制在1s之内。
以上是关于Redis持久化策略剖析的主要内容,如果未能解决你的问题,请参考以下文章