持久化
RDB
save
bgsave
- 工作原理
bgsave->发送指令到redis,redis返回Background saving started给客户端,然后调用fork函数生成子进程,子进程创建rdb文件,成功后返回消息给redis,可通过日志文件查看 - bgsave命令时针对save阻塞问题的优化。Reids内部所有涉及到RDB操作都采用bgsave的方式,save命令可放弃使用
问题
可能会忘记执行保存命令,因为不知道数据产生了多少变化,不知道何时保存数据
解决
自动执行
save second changes
- 作用
满足限定时间范围内key的变化数量达到指定数量即进行持久化 - 参数
second:监控时间范围
changes:监控key的变化量 - 位置
conf配置文件
AOF
RDB存储的弊端
- 存储量大时效率低,io性能低
- 基于fork创建子进程,内存产生额外消耗
- 宕机带来的数据丢失的风险
AOF概念
- 以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令达到恢复数据的目的
- AOF主要解决了数据持久化的实时性
AOF写数据三种策略
- always
每次写入操作均同步到AOF文件中,数据零误差,性能较低,不建议使用 - everysec
每秒将缓冲区中的指令同步到AOF文件中,数据准确性较高性能较高,在系统宕机的情况下丢失1秒的数据 - no
由操作系统控制每次同步到AOF文件的周期,整体过程不可控
AOF功能启动
- 配置
appendonly yes|no
appendfsync always|everysec|no
AOF重写
将同一个数据的若干条命令执行结果转化成最终结果数据对应的指令进行记录
- 作用
降低磁盘占用量,提高磁盘利用率
提高持久化效率,降低持久化写时间,提高io性能
降低数据恢复勇士,提高数据恢复效率 - 重写方式
手动重写:bgrewriteaof
自动重写:auto-aof-rewrite-min-size size/auto-aof-rewrite-percentage percentage
事务
一个队列中一次性、顺序性、排他性地执行一系列命令
标签:AOF,--,bgsave,redis,3linux,命令,save,数据 From: https://www.cnblogs.com/CAI-STUDY/p/17417926.html