Redis以下几种持久性选项范围:
下面着重介绍RDB和AOF持久化的特点和应用场景。
RDB 是 Redis 默认的持久化方案。在指定的时间间隔内,写操作达到指定的次数,则会将内存中的数据写入到磁盘RDB文件中。由于RDB文件是一个非常紧凑的文件,比较容易备份,所以RDB对于灾难恢复非常有用。RDB最大限度地提高了Redis的性能,因为Redis父进程的持久化操作是通过分叉子进程实现,而父进程不会执行磁盘I / O等操作。与AOF相比,RDB允许大型数据集更快地重启。
RDB持久化的写入方式决定了该持久化策略并不能完全保证数据的安全性。RDB需要经常使用fork()才能使用子进程将其持久化在磁盘上。如果数据集很大,Fork()可能很耗时,并且如果数据集很大且CPU性能不佳,则可能导致Redis停止为客户端服务几毫秒甚至一秒钟。该过程如果出现宕机,则可能造成数据丢失。
打开 redis.conf 文件,定位到 SNAPSHOTTING 对应内容
save <seconds> <changes>
# save ""
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb
dir ./
rdbcompression yes
save <指定时间间隔> <执行指定次数更新操作>,满足条件就将内存中的数据同步到硬盘中。官方出厂配置默认是 900秒内有1个更改,300秒内有10个更改以及60秒内有10000个更改,则将内存中的数据快照写入磁盘。关闭RDB,则把上面配置注释即可。
触发RDB快照的方式有save策略触发,flush命令(清空数据库所有数据),shutdown(关闭redis)命令,三种方式都是调用redis的bgsave机制实现快照触发。
RDB文件恢复数据的方式是将dump.rdb 文件拷贝到redis的安装目录的bin目录下,重启redis服务即可。
AOF可以弥补RDB的不足(数据的不一致性),它采用日志的形式来记录每个写操作,并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
使用AOF Redis更加持久,提供不同的fsync策略:完全没有fsync,每秒fsync,每个查询fsync。使用默认策略fsync时,每秒的写入性能仍然很好(fsync是使用后台线程执行的,并且在没有进行fsync的情况下,主线程将尽力执行写入操作。)
AOF日志是仅追加的日志,因此即便是断电故障,也不会出现磁盘寻道或损坏问题。即使由于某种原因(磁盘已满或其他)导致日志错误,也可以使用redis-check-aof工具=轻松修复。
对于同一数据集,AOF文件通常大于等效的RDB文件。在特定的fsync策略下,AOF比RDB的效率低。通常,在将fsync设置为每秒的情况下,性能仍然很高,并且在禁用fsync的情况下,即使在高负载下,它也应与RDB一样快。即使在巨大的写负载的情况下,RDB仍然能够提供有关最大延迟的更多保证。但是如果fsync策略为aways,则随着集群负载增大,AOF记录的内容越来越大多,文件会越来越大,数据恢复也会越来越慢。
打开 redis.conf 文件,定位到APPEND ONLY MODE 对应内容
appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
说明:
AOF主要根据配置文件策略触发,可以是每次执行触发,可以是每秒触发,可以不同步。
AOF的恢复主要是将appendonly.aof 文件拷贝到redis的安装目录的bin目录下,重启redis服务即可。但在实际开发中,可能因为某些原因导致appendonly.aof 文件异常,从而导致数据还原失败,可以通过命令redis-check-aof --fix appendonly.aof 进行修复
AOF的工作原理是将写操作追加到文件中,文件的冗余内容会越来越多。所以Redis 新增了重写机制,通过auto-aof-rewrite-min-size控制。当AOF文件的大小超过所设定的阈值时,Redis就会对AOF文件的内容压缩。
作者:张文博