什么是持久化?简单来说就是将数据放到断电后数据不会丢失的设备中,也就是咱们一般理解的硬盘上。缓存
首先咱们来看一下数据库在进行写操做时到底作了哪些事,主要有下面五个过程:安全
Redis持久化方式分为RDB和AOF。bash
RDB(Redis DataBase)持久化是在指定的时间间隔内将内存中的数据集快照写入磁盘。同时也是默认的持久化方式。服务器
save m n # 表示m秒内数据集存在n次修改时,自动触发bgsave
例如,如下能够同时配置:app
# 900秒内执行1次更新 save 900 1 # 300秒内执行10次更新 save 300 10 # 60秒内执行10000次更新 save 60 10000
# 指定本地数据库文件名,通常采用默认的dump.rdb dbfilename dump.rdb # 备份文件存放目录,通常也用默认配置 dir ./
配置存储至本地数据库时是否压缩数据,默认为yes
。Redis采用LZF压缩方式,但占用了一点CPU的时间。若关闭该选项,但会致使数据库文件变的巨大。建议开启。性能
rdbcompression yes
AOF(Append only file)持久化是以独立日志的方式记录每次命令,重启时再从新执行AOF文件中的命令达到恢复数据的目的。操作系统
AOF的主要做用是解决了数据持久化的实时性。线程
AOF直接采用文本协议格式(兼容性好),开启AOF后,全部写入命令都包含追加操做,直接采用文本协议格式,避免了二次处理开销。3d
AOF的工做流程操做:命令写入(append)、文件同步(sync)、文件重写(rewrite)、重启加载(load)。
流程以下:
默认不开启,启用AOF持久化方式
appendonly yes # AOF文件名称 appendfilename "appendonly.aof" # 备份文件存放路径,同RDB dir ./ # 同步频率 appendfsync everysec
appendfsync同步频率配置参考:
aof_buf
后调用fsync
操做同步到AOF文件,fsync
完成后线程返回,每一个 Redis 命令都要同步写入硬盘,这样会严重下降 Redis 的性能。aof_buf
后调用系统write
操做,write
完成后线程返回。fsync
同步文件操做由专门线程每秒调用一次。每秒执行一次同步,显式地将多个写命令同步到硬盘。aof_buf
后调用系统write
操做,不对AOF文件作fsync
同步,同步硬盘操做由操做系统负责,一般周期周长30秒。操做系统同步AOF文件的周期不可控,会加大每次同步硬盘的数据量,数据安全性没法保证。随着命令不断写入AOF,文件会愈来愈大,为了解决这个问题,Redis引入AOF重写机制压缩文件体积。AOF文件重写是把Redis进程内的数据转化为写命令同步到新AOF文件的过程。
重写后的AOF文件为何能够变小?有以下缘由:
del key1
、hdel key2
、srem keys
、set a1111
、set a222
等。重写使用进程内数据直接生成,这样新的AOF文件只保留最终的数据写入命令。lpuh list a
、lpush list b
、lpush list c
能够转化为:lpush list a b c
。为了防止单条命令过大形成客户端缓冲区溢出,对于list
、set
、hash
、zset
等类型操做,以64个元素为界拆分为多条。AOF重写不只下降了文件占用空间,并且更小的AOF文件能够更快地被Redis加载。
触发方式:
bgrewriteaof
命令;auto-aof-rewrite-min-size:表示运行AOF重写时文件最小体积,默认为64MB。 auto-aof-rewrite-percentage:表明当前AOF文件空间(aof_current_size)和上一次重写后AOF文件空间(aof_base_size)的比值。 自动触发时机=aof_current_size>auto-aof-rewrite-minsize&&(aof_current_size-aof_base_size) /aof_base_size>=auto-aof-rewritepercentage
流程说明:
日志:
* DB loaded from append only file: 5.841 seconds
* DB loaded from disk: 5.586 seconds
因为RDB持久化和AOF持久化都有各自的优缺点,所以在很长一段时间里,如何选择合适的持久化方式成了不少Redis用户面临的一个难题。为了解决这个问题,Redis从4.0版本开始引入RDB-AOF混合持久化模式,这种模式是基于AOF持久化模式构建而来的。