Redis - 缓存持久化

Redis 的缓存持久化有两种技术 : RDB 和 AOF

RDB

Redis 的数据快照

简单说就是将缓存中的所有数据都记录到磁盘中,当Redis发生故障的时候,只需读取快照文件,就可恢复数据

相应的命令是 save 和 bgsave ,这两个命名都可以手动执行RDB持久化,不过

  • save 由 Redis 主线程来执行RDB,会阻塞所有命令
  • bgsave 开启子线程执行RDB,主线程不受影响

如果每次RDB都需要手动输入save或bgsave命令未免太麻烦

因此Redis内部有RDB触发机制,格式 :save [时间] [key的修改次数] 比如 save 300 1 表示300秒内至少有一个key被修改了,则执行 bgsave

AOF

AOF全称 Append Only File (追加文件)。Redis 处理的每一个写命令都会记录在AOF文件中,相当于一个命令日志文件

AOF 的开启方法

找到 redis.conf 文件,其中有一行语句是 appendonly no,因为Redis默认关闭AOF,改为appendonly yes,就可开启AOF,下面还有一行语句 appendfilename "appendonly.aof" 指定AOF文件名

设置 AOF 的记录频率

AOF的执行频率也叫刷盘策略,同样是通过redis.conf 文件进行配置,总共有三档频率

  • appendfsync always : 同步刷盘,每执行一次写命令,就立刻记录到AOD文件
  • appendfsync everysec : 每秒刷盘,写命令先放入AOF缓冲区,然后每隔一秒将缓冲区数据写到AOF文件,这是Redis默认的AOF刷盘策略
  • appendfsync no:操作系统控制,写命名都先放入AOF缓冲区,由操作系统决定何时将缓冲内容写回磁盘

三种刷盘策略由上到下,性能原来越好,但可靠性越来越差,因此实际开发过程中大部分选择 appendfsync everysec 刷盘策略

另外 AOF文件比RDB文件要大的多,而且AOF会记录对同一个key的多次写操作,但只有最后一次是有效的。我们可以通过 bgrewriteaof 命令,让AOF文件执行重写功能,用最少的命令达到相同的效果

比如: set num 1 set name zyj set num 3

执行bgrewriteaof命令后,可重写为 mset name zyj num 3

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在redis.conf中配置:

  • 找到语句 auto-aof-rewrite-percentage [百分比],该语句表示 AOF文件比上次文件增长超过多少百分比触发重写
  • 语句 auto-aof-rewrite-min-size [AOF文件大小],该语句表示AOF文件达到多大就触发重写

RDB 和 AOF 对比

RDB - 优点 : 文件小; 宕机恢复速度快
缺点 : 数据完整性较低; 占用的CPU和内存资源较大

AOF - 优点 :数据完整性较高; 在记录时占用的CPU和内存资源较小(但重写的时候占有很大) 缺点 :文件体积大,较占用磁盘空间;宕机恢复速度较慢

RDB和AOF各有自己的优缺点,如果对数据安全性要求较高,在实际开发中往往会结合两者来使用。

end

评论

新增邮件回复功能,回复将会通过邮件形式提醒,请填写有效的邮件!