4.redis持久化
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”
最佳策略
“小分片”
“缓存或者存储”
“监控(硬盘、内存、负载、网络)”
“足够的内存”