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持久化流程
- 客户端的请求写命令会被append追加到AOF缓冲区内;
- AOF缓冲区根据AOF持久化策略[always,everysrc,no]将操作sync同步到磁盘的AOF文件中;
- AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量;
- Redis服务重启时,会重新加载AOF文件的写操作,达到数据恢复的目的;
AOF重写流程
重写流程与rdb一致,写时复制。
AOF优势
- 备份机制更稳健,丢失数据概率更低
- 可读的日志文件,通过操作AOF文件,可以处理错误操作
AOF劣势
- 比起RDB占用更多的磁盘空间
- 恢复备份速度更慢
- 每次读写都同步会有一定的性能压力
- 存在个别Bug,造成无法恢复
RDB和AOF如何选择
- 如果对数据不敏感,可以只用RDB
- 如果只是纯粹内存缓存,可以都不用
本文来自博客园,作者:Laplace蒜子,转载请注明原文链接:https://www.cnblogs.com/RedNoseBo/p/16244188.html
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· NetPad:一个.NET开源、跨平台的C#编辑器