redis 持久化

 

Redis有两种持久化方案，RDB（Redis DataBase）和AOF（Append Only File）

 

一、RDB

redis的RDB方案是一种快照方式持久化，就是在某时刻把所有数据进行完整备份。RDB是redis默认的持久化方案，它的作用是一旦在指定的时间间隔内，执行指定次数的写操作，redis服务会将内存中的数据写入磁盘中，默认是写入/var/lib/redis/dump.rdb 文件，redis重启会通过加载dump.rdb文件恢复数据

从配置文件了解RDB

打开 /etc/redis.conf 文件，找到SNAPSHOTTING部分内容

################################ SNAPSHOTTING  ################################
#   save <seconds> <changes>
# 下面第一行的意思是如果900内至少有一个键被改动，自动进行数据保存，若不想使用RDB持久化可以把所有
#save配置注释掉，或者添加一行 save ""
save 900 1
save 300 10
save 60 10000

# 若redis最近一次持久化到dump文件出错，则默认不允许进行写操作，改成no则无视持久化错误允许写操作
stop-writes-on-bgsave-error yes

# 压缩dump持久化文件，改成no不压缩文件会变大很多，不过能节一点cpu，建议使用默认值yes
rdbcompression yes

#持久化文件校验，会消耗一些性能，建议使用默认值yes
rdbchecksum yes

# RDB持久化文件名
dbfilename dump.rdb

# 持久化文件存储目录，即dump文件所在目录，aof文件也会放在这个目录下
dir /var/lib/redis

触发RDB快照的几种方式

save         此命令是同步命令，在持久化时会阻塞所有客户端请求

bgsave     异步命令，会生成一个子进程将内存数据保存到dump文件，不影响主进程服务。通过配置文件save属性触发的持久化也是通过bgsave方式保存，新建进程会消耗内存

flushall     此命令在清空redis数据后会进行持久化操作

shutdown  使用shutdown命令会先进行持久化操作再关闭服务

优缺点

优点：

  紧凑的单一文件，适用于灾难恢复

  与aof相比，在恢复大的数据集时，RDB方式会更快

缺点：

  RDB需要经常生成子进程来进行数据持久化，耗时、耗性能

  数据完整性不高，根据配置，一旦发生redis意外宕机可能会丢失几分钟的数据

 

二、aof

redis的aof备份是一种写日志方式持久化，就是将用户所有的写指令备份到文件中，还原数据时会将所有指令重新执行一遍。redis默认不开启aof，redis中RDB和aof两种持久化方式能同时使用

aof重写

因为aof的运作方式是不断将命令追加至文件的末尾，随着写入命令的不断增加，aof文件体积会变得越来越大。比如，对一个计数器调用了100此incr，那仅仅为了保存一个值aof文件就需要使用100条记录。这样不止会造成aof文件体积过大，还会导致数据恢复时速度太慢。而实际上只用一条set命令就足以保存计数器当前值了。

为了处理这种情况redis支持bgrewriteaof重写命令，用于异步执行aof文件重写操作，上面的100条记录变成1条。它会创建一个当前aof文件的优化版本，而即使bgrewriteaof执行失败，也不会有任何数据丢失，因为旧的aof文件在bgrewriteaof成功之前不会被修改。redis在一定条件下会自发进行重写，也可以调用bgrewirteaof命令主动重写

从配置文件了解aof

打卡/etc/redis.conf 文件，找到 APPEND ONLY FILE 部分

# 为了解决RDB一致性问题而生，默认不开启
appendonly no

#保存文件名
appendfilename "appendonly.aof"

# aof实际上是调用fsync()让系统将内存中数据保存到磁盘上，有些系统会立即保存，有些系统只能做到“尽可能快”保存
#redis支持三种模式来调用fsync():
#no: 不调用，系统按自己步调保存内存数据到磁盘
#always：每一次写操作都调用
#everysec： 每秒调用一次
# appendfsync always
appendfsync everysec
# appendfsync no

# aof的fsync虽然是一个单独线程，但是它还是会阻塞redis的同步写操作，而RDB的bgsave和aof的bgrewriteaof(重写，从后面了解）
# 会占用大量的I/O，是fsync阻塞住，那就意味着阻塞同步写操作。下面属性意思是不在bgsave或bgrewriteaof时
# 调用async，如果填yes最坏情况有可能导致丢失30秒的日志。为了数据一致性默认填no

no-appendfsync-on-rewrite no

#下面两个用于配置自动重写的触发条件。只有两个条件都满足才触发
#第一个当前aof文件比上一次重写后aof文件增加的百分比，如果是0则aof不会自动重写，如果没有上一次
#重写则按redis服务启动时aof文件大小算
#第二个表示aof文件至少要达到这个大小才重写，主要为了防止aof文件很小的时候经常触发重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 在一些时候会发生aof文件最后面记录出问题，比如服务奔溃aof一行记录写到一半
#下面这个属性yes表示在恢复数据时碰到最后一条问题记录会记录下来但是不影响前面数据恢复，no则直接恢复失败
aof-load-truncated yes

优缺点

优点：

  redis更耐久，使用默认的每秒fsync策略，能保证最多丢失1秒的数据，而性能依旧很好

  有序的保存了对数据库的操作，易读。比如不小心执行flushall命令，找到aof文件，移除末尾的flushall命令，就能恢复数据

缺点

  相同数据集下，aof文件体积通常要大于RDB文件体积

  aof的数据恢复速度可能会低于RDB不过是可以接受的