Contents
什么是持久化?
redis所有数据保存在内存中,对数据的更新将异步地保存在磁盘上
内存->磁盘:存储数据避免丢失
磁盘->内存:恢复数据
持久化的方式
什么是RDB?
RDB一条命令,将redis生成一个完整的快照存储在我们的硬盘中。他也是一种复制的媒介。
触发机制-三种方式
- save(同步)
- 发送执行一条save命令,自动生成RDB文件
-
对数据进行完整的备份,对其他的客户端造成阻塞作用
-
存储策略创建一个临时的新的备份文件,完全备份后替换新的老的备份文件
-
因为是完全备份所以复杂度为O(N)
- bgsave(异步)
- 同步和异步的区别
- 自动
- 自动不是一种很好的方式
-
无法提前预知将要到来的访问量
-
频繁的读写磁盘对磁盘造成很大的压力
-
策略的定制尤为重要
触发机制-不可忽视的方式
- 全量复制(主从,主自动生成RDB文件)
-
debug reload(不清空数据重启)
-
shutdown(RDB文件的生成)
实际工作运用
RDB存在的问题
- 耗时、耗性能
- O(n)数据:耗时
- fork(),消耗内存,copy-on-write策略
- DISK I/O:I/O性能的消耗
- 不可控、丢失数据
时间戳 | save |
---|---|
T1 | 执行多个写命令 |
T2 | 满足RDB自动创建的条件 |
T3 | 再一次执行多个写命令 |
T4 | 再次执行多个写命令 |
T5 | 宕机 |
RDB总结
- 在进行大规模的数据恢复的时候选择,RDB性能比AOF要好
-
1.RDB是Redis内存到硬盘的快照,用于持久化
-
2.save通常会阻塞Redis
-
3.bgsave不会阻塞Redis,但是会fork新的进程占用内存
-
4.save自动配置满足任意一个结果就会执行
-
5.对于触发机制需要注意
持久化的取舍和选择
简单的理解AOF
– 只追加操作的文件
- Append Only File
-
记录redis服务所有的写操作
-
不断的将新的写操作,追加到文件的末尾
-
使用cat命令查看
AOF运行原理
创建
恢复
AOF的三种策略
- always
- everysec
- no
三种模式的比较
生产环境下
- 生产环境中根据硬盘的质量,一般的SATA盘一次写量达于100多算很好的硬盘了。
-
redis默认的方式时eversec模式
-
no模式不可控,所以实际生产中是不会去使用的。
-
现在比较好的固态或IPCE盘可以考虑使用always模式
AOF重写
为什么要AOF重写?
重写的作用
- 减少硬盘占用量
-
加速恢复速度
-
通俗:将过期的没用的可以合并优化的空的,化减成一个简单的AOF文件
AOF重写实现的两种方式
- bgrewriteaof -> 类似bgsave:调用fork()子进程完成AOF重写的过程,类似RDB
- AOF重写配置
- AOF重写条件
自动触发机制 -> 同时满足
- 当前文件尺寸>原来的文件尺寸
- (当前的文件尺寸-上一次文件尺寸)/上一次尺寸>设置的增长率
AOF重写的流程
AOF的配置文件
- appendonly yes #开启AOF模式
-
appendfilename “appendonly-${port}.aof” #设置用端口进行区分
-
appendfsync eversec #AOF同步的策略
-
dir /路径 #当访问量比较达的时候存放的位置
-
no-appendfsunc-on-rewrite yes #AOF重写时候是否做完整append操作。设置优先级
-
auto-aof-rewrite-percentage 100 #增长率
-
auto-aof-rewrite-min-size 64mb #最小的尺寸
-
aof-load-truncated yes #是否忽略错误
RDB和AOF的抉择
RDB与AOF的对比
RDB的最佳策略
-
无论是主还是从最好都是关闭RDB
-
集中管理:按照天或小时备份数据最好使用RDB
-
主从,打开
AOF的最佳策略
-
开:缓存和存储
-
AOF重写集中管理
-
eversec 按照秒刷新
两个的参考策略
-
小分片:max_mem最大内存设置一个量一般都是4G,产生小的开销。
-
缓存或是存储
-
监控(硬盘、内存、负载、网络)
-
足够大的内存