一站式学习Redis， 从入门到高可用分布式实践-05-06持久化
redis持久化的取舍和选择
- 什么是持久化
- redis所有数据保存在内存当中，对数据的更新将异步保存到磁盘上
- 持久化方式
- 快照 --- redis RDB(mysql dump)
- 写日志 --- redis AOF (mysql binlog)(hbase hlog)
- RDB
- 触发机制-三种方式
save同步，会造成redis客户端阻塞，文件策略：如果存在老的rdb文件，新的会替换掉老的文件
bgsave异步，不会造成redis客户端阻塞，文件策略：与save相同
自动
-
save与bgsave的区别
配置文件:
dbfilename dump.rdb
最佳配置：
-
rdb持久化的三种方式，save,bgsave，配置文件设置自动备份时间
-
RDB总结：
- rdb是redis内存到硬盘的快照，用于持久化
- save通常会阻塞redis
- bgsave不会阻塞redis,但是会fork一个新的进程
- save自动配置满足任意一个条件就会被执行
- 有些触发机制不容忽视，比如主从复制、shutdown
- redis的持久化方式AOF
- RDB现存问题：
耗时、好性能
不可控，容易丢失数据
- AOF的运行原理
- 创建：没当redis有更新命令时就会写入aof文件
- 恢复：当redis重启时就会把aof文中中的命令重新执行一遍，所有数据就恢复到内存了
- AOF的三种策略
- always
- everysec
- no
redis写命令先刷新到缓冲区，然后每条命令fsync到硬盘（always）
redis写命令刷新到缓冲区，然后每隔一秒把缓冲区fsync到硬盘（everysec）
redis写命令刷新到缓冲区，然后os决定何时吧缓冲区fsync到硬盘（no）
-
always、everysec、no优缺点比较
-
AOF重写
- AOF重写的作用：减少磁盘的占用量，加速恢复速度
- AOF重写实现的两种方式：bgrewriteaof、aof重写配置
-
aof的bgrewriteaof
aof的重写就是将内存中的数据进行回溯 -
aof重写配置
-
AOF重写流程
-
AOF配置
-
AOF实验
config set appendonly yes # 开启aof
bgrewriteaof
打开data目录下的appendonly.aof文件查看，发现添加的命令被bgrewriteaof重写了
- RDB与AOF对比
18 RDB的最佳策略
"关"、集中管理、主从，从开？
-
AOF的最佳策略
"开":缓存和存储
AOF重写集中管理
AOF策略选择everysec -
最佳策略
小分片、缓存或者存储、监控（硬盘、内存、负载、网络）、足够的内存
常见的持久化开发运维问题
- fork操作
- 同步操作
- 与内存量息息相关：内存越大，耗时越长（与机器类型有关）
- info: latest_fork_usec
1.1 改善fork
- 优先使用物理机或者高效支持fork操作的虚拟化技术
- 控制redis实例的最大可用内存maxmemory
- 合理配置linux内存分配策略，vm.overcommit_memory=1
- 降低fork频率，例如放宽aof重写自动触发时机，不必要的全量复制
- 进程外开销（子进程开销和优化）
2.1 CPU开销
- RDB和AOF文件生成，属于CPU密集型
- 优化：不做CPU绑定，不和CPU密集型部署
2.2 内存 - 开销：fork内存开销，copy-on-write
2.3 硬盘 - 开销：AOF和RDB文件的写入，可以结合iostat iotop分析
2.4 硬盘优化 - 不要和高硬盘负载服务部署在一起：存储服务，消息队列等
- no-appendfsync-on-rewrite yes
- 根据写入量决定磁盘类型：ssd
- 单机多实例持久化文件目录可以考虑分盘
- AOF追加阻塞
3.1 AOF阻塞定位
- redis日志
