持久化
1.redis持久化:redis所有数据保存在内存中，对数据的更新将异步保存到磁盘中
2.主流数据库持久化:快照；写日志
RDB
1.redis对当前数据进行快照,生成RDB文件（二进制）保存到磁盘中，redis重启后载入RDB文件，以恢复数据
2.触发机制
save(同步，会造成阻塞) O(N)
命令行直接输入save，执行时会生成RDB文件，执行完毕会将老的文件替换
save
#返回OK 表示执行成功
不会消耗额外内存
bgsave(异步,生成子进程操作,阻塞发成在子进程) O(N)
命令行直接输入bgsave
bgsave
#返回Background saving started 表示操作开始
需要子进程fork,需要消耗额外内存
间接触发机制
1.全量复制
2.debug reload
3.shutdown
自动生成策略
900s内有1条数据变化
300s内有10条数据变化
60s内有10000条数据发生变化
以上3中满足1个条件就会触发自动生成，自动生成本质是bgsave
默认配置
save 900 1
save 300 10
save 60 10000
dbfilename dump.rdb # 名字叫dump.rdb
dir ./ # 默认存在当前文件
stop-writes-ob-bgsave-error yes # 当bgsave发生错误，默认停止写入
rdbcompression yes # 是否采用压缩，默认是
rdbchecksum yes # 是否进行校验，默认是
最佳配置
# 建议不适用save
dbfilename ${port}.rdb # 一般开启多个,适用其端口号
dir /diskpath #专门存放数据的文件夹
stop-writes-ob-bgsave-error yes
rdbcompression yes
rdbchecksum yes
RDB 总结
1.RDB 是Redis内存到硬盘的快照，用于持久化
2.save通常会阻塞Redis
3.bgsave不会阻塞Redis，但是会生成fork新进程消耗内存
4.save自动配置满足任意就会被执行
5.有些触发机是间接的
缺点
耗时、耗性能、耗内存
不可控、丢失数据：
AOF
类似于数据库的日志,每写入一个命令就同时会保存到AOF文件,当发生宕机后,将AOF文件导入到redis
策略
always:每写一条命令就写入AOF。不丢失数据；I/O开销大
everysec:每秒将redis缓冲区的命令写入到AOF。I/O开销相对较小；丢失1秒数据
no:OS决定。完全由系统决定,不可控
AOF重写
将过期的、没有用的、冗余的命令进行化简成很小的AOF
作用:加速恢复速度，减少磁盘占用
AOF重写的两种方式
bgrewriteaof:执行此命令,redis会创建一个子进程,将缓冲区的所有命令回溯,替换原有的AOF
AOF重写配置:
建议配置
appendonly yes # AOF的所有功能打开
appendfilename "appendongly-${port}.aof" #aof文件名
appendfsync everysec
dir /diskpath
no-appendfsync-on-rewrite yes
动态更改配置
config set name value
持久化运维
fork操作
1.同步操作
2.与内存量息息相关:内存越大,耗时越长（与机器类型有关）
3.info:latest_fork_usec (最近一次fork操作的时常，微秒)
改善fork
1.优先使用物理机或者高效支持fork操作的虚拟化技术
2.控制Redis实例最大的可用内存:maxmemory
3.合理配置Linux内存分配策略:vm.overcommit_memory=1
4.降低fork频率:例如放宽AOF重写自动触发时机,不必要的全量复制
子进程开销和优化
1.CPU:
开销:RDB和AOF文件生成,属于CPU密集型
优化:不做CPU绑定,不和CPU密集型部署
2.内存
开销:fork内存开销,copy-on-write
优化:不允许单机多部署时进行大量的重写；linux优化策略 echo never > /sys/kernel/mm/transparent_hugepage/enabled
3.硬盘
开销:AOF和RDB文件写入
优化:不要和高硬盘负载服务部署一起:存储服务,消息队列等；
no-annpendfsync-on-rewrite=yes;
根据写入量决定磁盘类型:例如ssd;
单机多实例持久化文件目录可以考虑分盘
AOF追加阻塞
AOF阻塞定位
