RDB与AOF

RDB

RDB启动方式

save指令

手动执行一次保存操作

save

redis是单线程执行任务的
不同客户端发送来四个指令 set set save get
在这里插入图片描述save指令的执行会阻塞当前Redis服务器,直到RDB过程完成为止,
有可能长时间阻塞,所以线上环境不建议使用

bgsave

数据量过大的时候,单线程执行方式造成效率过低。如何处理?
后台执行(不是立即执行)
bgsave

执行过程:
直接生成一个子进程来完成这部分操作
在这里插入图片描述
bgsave命令是针对save阻塞问题做的优化,Redis内部所有涉及RDB操作都采用bgsave方式

自动执行

配置:save second changes
满足限定时间范围内key的变化数达到changes数量的时候进行持久化
后台还是使用的bgsave
在这里插入图片描述

AOF

RDB的弊端:
存储数据量大的时候效率较低(基于快照的思想,数据量大的时候效率低)
大数据量下的IO性能较低
基于fork创建子进程,内存产生额外消耗
宕机带来数据丢失的风险(因为不是实时的)

解决思路:
对所有的操作过程进行记录

AOF的主要作用是解决了数据持久化的实时性
AOF
将命令写入到aof文件中
在这里插入图片描述
什么时候写入?
always(每次)
每次写入操作都写入,性能较低,不建议使用
eversec(每秒)
每秒将缓冲区中的数据同步到AOF中,准确度较高,性能高,建议使用
系统宕机时丢失1s数据
no(系统控制)
操作系统控制,整体不可控

AOF功能开启

配置文件中:
appendonly yes:是否开启AOF,默认不开启
appendfsnc always|everysec|no :AOF写数据策略

重写
重写规则:
进程内已经超时的数据不再写了
对同一条数据的多个写命令合并成一条命令

在这里插入图片描述
手动重写指令
bgrewriteaof

自动重写

AOF与RDB区别

在这里插入图片描述
RDB与AOF的选择
对数据非常敏感,建议使用默认的AOF持久化方案
持久化策略使用everysecond,保持很好的性能,出现问题的时候,丢失0-1s的数据
如果接受数分钟的数据丢失并且要大数据的快速恢复,用RDB

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值