1. 什么是持久化
redis所有数据保持在内存中,对数据的更新将异步地保存到磁盘中。
2. 持久化的方式
快照—mysql dump或者redis rdb
写日志—mysql binlog或者hbase glog或者redis aof
3. RDB
什么是RDB
触发机制三种主要方式
- save(同步)
save是同步的,当保存的数据量很大时,可能造成redis的阻塞,即客户端访问redis被阻塞。
他的文件策略是:如果存在老的RDB文件,则新的替换老的。复杂度为O(n)。
- bgsave(异步)
一般情况下,fork是比较快的,但是也可以会慢,这时会阻塞redis。只要fork不慢,客户端不会被阻塞。
他的文件策略和复杂度与save是一样的。
save和bgsave两者对比:
- 自动
redis的自动保存的默认配置是:
配置 | seconds | changes |
---|---|---|
save | 900 | 1 |
save | 300 | 10 |
save | 60 | 10000 |
就是说,在60秒内改变了10000条数据,就自动保存;在300秒内有10条改变才自动保存;900秒内有1一条改变就保存。
RDB总结
- RDB是Redis内存到硬盘的快照,用于持久化。
- save通常会阻塞redis。
- bgsave不会阻塞redis,但是会fork新进程。
- save自动配置满足任一就会被执行。
- 有些触发机制不容忽视。
4. AOF
RDB问题
O(n)数据的备份,很耗时间;对于bgsave来说,fork()是一个很消耗内存的操作;将数据全写到硬盘,必然对硬盘IO占用很大。
还有一点是:某个时间点宕机,那么在某个时间段的数据就丢失了。
AOF原理
将对redis的操作追加到aof文件中。当redis宕机之后,使用aof恢复所有的操作继而实现数据的恢复。
AOF三种策略
- always
- everysec
redis出现故障,有可能丢失一秒的数据。redis默认方式。
- no
三种策略的比较
AOF重写
好处是:减少硬盘占用量、加速恢复速度
实现的两种方式:bgrewriteaof和aof重写配置
bgrewriteaof
注意:这里的重写并不是上面演示的,将原来的aof文件进行重写,而是对redis的内存数据进行一次回溯。
aof重写流程
5. 持久化的取舍和选择
RDB和AOF对比
RDB最佳策略
“关”:建议关闭,但是后面主从复制功能是需要他的,因为需要主节点执行dbsave,然后将rdb文件传给从节点。所以说,关不是永久关。
“集中管理”:虽然RDB很重,但是对于数据备份是很重要的,按照小时或者天集中地进行备份比较好,因为他的文件很小,利于传输。
“主从,从开”:有时候从节点打开这个功能是比较好的,但是备份太频繁,取决于实际的场景。
AOF最佳策略
“开”:建议打开,如果仅仅是作为一个普通缓存,对于数据要求不是很高,这次数据丢了,下次可以从数据库取(数据库压力不是很大),这种情况就建议关闭,因为AOF还是有性能开销的。
“AOF重写集中管理”
“everysec”
最佳策略
“小分片”
“缓存或者存储”
“监控(硬盘、内存、负载、网络)”
“足够的内存”