Redis持久化

Redis中两种持久化方式

  • RDB(Redis DataBase)
  • AOF(Append Of File)

RDB(Redis DataBase)方式

指定的时间间隔内,将内存中的数据集快照写入磁盘。恢复数据的时候,将磁盘文件中内容读取到内存。

Redis会单独创建(fork)一个子进程来处理持久化,这个子进程会将数据写入到一个临时文件中,再用这个临时文件替换上次持久化好的文件。

关键词:快照写入,间隔写入。

优势:主进程不进行任何IO操作,确保了极高的性能。

缺点:最后一次持久化后的数据可能丢失。

配置文件

  • dbfilename    -用于指定rdb文件名称

  • stop-writes-on-bgsave-error    -开启后,当Redis无法写入磁盘,直接关掉Redis的写操作

  • rdbcompression yes    -开启后,redis会采用LZF算法机型压缩存储磁盘中的快照,需要消耗一定的CPU性能

  • rdbchecksum yes    -开启后,存储快照完成时redis会使用CRC64算法来进行数据校验。该操作大概有10%的性能消耗

  • save <seconds> <keyNumber>    - 作用是指定秒数内,若有指定个数的key发生变化,就会存储。save是只管保存,其他不管,全部阻塞,不建议使用

  • bgsave <seconds> <keyNumber>    -作用与save一致,只不过此方法是异步操作

RDB优势

  • 适合大规模的数据恢复
  • 对数据完整性和一致性要求不高更适合使用
  • 节省磁盘空间
  • 恢复速度快

劣势

  • 保存临时文件时,内存中的数据被克隆了一份,大致两倍的膨胀性需要考虑
  • Redis在fork时使用了写时拷贝技术,但是如果数据庞大还是比较消耗性能
  • 在即将保存时候,如果Redis以外崩了,那么最后一次数据保存可能会丢失

rdb的备份与恢复

通常dump.rdb文件都保存在redis-server的同级下,可以将这个dump.rdb文件备份到其他位置。

将备份的dump.rdb文件放到redis-server的同级下,启动redis时会自动加载。

动态停止RDB

使用命令:redis-cli config set save ""


AOF(Append Only File)

以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来,只许追加文件但不可以改写文件

redis启动时候会读取该文件命令然后执行,以此来重新构建数据。

关键词:只保存写;增量保存;

AOF的设定

AOF默认不开启,在redis.conf配置文件中默认名字为“appendonly.aof”

AOF和RDB同时开启,系统默认采用AOF的数据

AOF的备份与恢复

AOF的备份和恢复操作同RDB一样

 

正常恢复

在redis.conf中,将appendonly no,改为yes,将有数据的aof文件复制一份保存到对应目录

异常恢复

在redis.conf中,将appendonly no,改为yes

如果遇到AOF文件损坏,通过/usr/local/bin/redis-check-aof --fix appendonly.aof进行恢复

备份被写坏的AOF文件

重启redis。

AOF同步频率设置

appendfsync always    -每次Redis的写入都会立刻记入日志

appendfsync everysec    -每秒记入日志一次

appendfsync no    -不主动同步,把同步时机交给操作系统

Rewrite压缩

AOF采用文件追加方式,文件会越来越大为避免出现此情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩。

只保留恢复数据的最小指令集。

重写原理

如有两条指令:set a a1和set b b1,重写后会压缩为set a a1 b b1。

触发机制

Rdis会记录上次重写时的AOF大小,默认配置是当AOF文件代销是上次rewrite后大小的一倍且文件大于64M时触发。

虽然重写可以节省大量磁盘空间,减少恢复时间,但是每次重写还是有一定的负担。英雌设定Redis要满足一定条件才会进行重写

auto-aof-rewrite-percentage    -设置重写的基准值,文件达到100%是开始重写

auto-aof-rewrite-min-size    -设置重写的基准值,最小文件64MB。达到这个值开始重写

 

AOF持久化流程

  1. 客户端的请求写命令会被append追加到AOF缓冲区内;
  2. AOF缓冲区根据AOF持久化策略[always,everysrc,no]将操作sync同步到磁盘的AOF文件中;
  3. AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量;
  4. Redis服务重启时,会重新加载AOF文件的写操作,达到数据恢复的目的;

AOF重写流程

重写流程与rdb一致,写时复制

AOF优势

  • 备份机制更稳健,丢失数据概率更低
  • 可读的日志文件,通过操作AOF文件,可以处理错误操作

AOF劣势

  • 比起RDB占用更多的磁盘空间
  • 恢复备份速度更慢
  • 每次读写都同步会有一定的性能压力
  • 存在个别Bug,造成无法恢复

RDB和AOF如何选择

  • 如果对数据不敏感,可以只用RDB
  • 如果只是纯粹内存缓存,可以都不用
posted @   Laplace蒜子  阅读(32)  评论(0编辑  收藏  举报
(评论功能已被禁用)
相关博文:
阅读排行:
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· NetPad:一个.NET开源、跨平台的C#编辑器
点击右上角即可分享
微信分享提示