1.持久化概念：
redis支持 将内存中的数据持久化到磁盘中,在下次启动redis时可以将磁盘中的数据加载到内存中
2.持久化通用的两种方式:
- 快照(某一时刻对数据的备份)
例如：mmysql dump redis RDB - 记录日志()
例如：Mysql binlog Hbase Hlog redis AOF
3.redis持久化之 RDB(redis database)
①RDB概念：
②触发机制-主要三种方式：
(1) save(同步)
(2)bgsave(异步)
(3)自动(符合配置文件中 save满足条件)
save与bgsave
| \命令 | save | bgsave |
|---|---|---|
| IO类型 | 同步 | 异步 |
| 阻塞 | 是 | 否(阻塞仅仅会发生在fork出子进程) |
| 复杂度 | O(n) | O(n) |
| 优点 | 不消耗额外内存 | 不阻塞客户端命令 |
自动生成RDB
save <seconds> <changes>
save 900 1
save 300 10
save 60 10000
释义：
60秒改变10000次,会采用bgsave方式生成RDB文件
300秒改变10次,会自动生成RDB文件
③RDB配置相关
# 每多少秒 数据改变几次
# 满足下面任一条件进行RDB文件生成
#如果线上环境数据量很大时，可以关闭RDB持久化方式 只需要注释下面三个save即可
save 900 1
save 300 10
save 60 10000
#bgsave生成RDB文件出错时是否停止
stop-writes-on-bgsave-error yes
#RDB文件是否采用压缩
rdbcompression yes
#是否对rdb文件校验和校验
#redis 5之后采用CRC64校验方式
rdbchecksum yes
# rdb文件名字
# 目录位置 采用 dir设置
dbfilename dump-6379.rdb
#指定目录路径非文件名
# rdb文件aof文件均采用此目录
dir ./
④可能忽略RDB触发机制
(1)全量复制
从节点执行全量复制操作的时候，主节点会自动触发bgsave命令生存rdb文件并发送给从节点
(2)debug reload
Redis中的debug reload提供debug级别的重启，不清空内存的一种重启，这种方式也会触发RDB文件的生成。
(3)shutdown
RDB存在问题:
① 耗时、耗性能
复杂度为o(n)，save时内存数据dump到磁盘：耗时
bgsave时，fork()阶段采用copy-on-write策略，会比较耗内存
dump到文件造成io开销
②不可控，丢失数据
| 时间戳 | save、bgsave |
|---|---|
| T1 | 执行多个命令 |
| T2 | 满足RDB自动创建条件 |
| T3 | 再次执行多个命令 |
| T4 | 宕机 |
在T4时刻redis出现宕机,会导致T3-T4时刻的数据丢失
如何解决？ 请看下一节AOF持久化方式吧
4.redis持久化之AOF(Append-only file)
client每次请求redis，都会将写请求的命令保存到文件中，
①AOF三种策略
① always
只要缓冲区有数据 立马写入文件中
②everysec
每隔一秒将数据从缓冲区写入文件中
③no
写文件的操作交由操作系统控制
AOF三种策略比较
| 命令 | always | everysec | no |
|---|---|---|---|
| 优点 | 不丢失数据 | 每秒一次fsync只丢失1秒数据 | 交由操作系统fsync,不用管 |
| 缺点 | 磁盘开销较大,一般sata磁盘一秒只有几百TPS | 丢失1秒数据 | 交由操作系统fsync,不可控 |
总结：
是业务情况,场景而定，一般可以使用everysec,在磁盘开销及数据丢失情况取个折中
aof相关配置
#是否启用AOF持久化方式
appendonly no
#AOF文件名
#目录受Dir控制
appendfilename "appendonly-6379.aof"
#AOF持久化策略
#默认值 everysec
# 有三种 no everysec always
#no 写文件的操作交由操作系统控制
#always 只要缓冲区有数据 立马写入文件中
#everysec 每隔一秒将数据从缓冲区写入文件中
appendfsync everysec
#aof重写期间主进程是否继续讲日志从缓冲区刷新到旧日志文件(上图aof_buf-<旧aof文件)
no-appendfsync-on-rewrite no
#以下两个配置同时满足即可触发AOF重写
#文件增长率
auto-aof-rewrite-percentage 100
#aof重写需要的文件
auto-aof-rewrite-min-size 64mb
②AOF重写
引入原因：
随着数据的不断写入,会造成AOF文件不断增大,重复的命令会额外占用磁盘空间,而是增加redis重启速度
AOF重写定义：
AOF文件重写不是对原有AOF文件进行读取分析,而是读取最新的数据进行分析实现的。
AOF重写作用：
1.减少磁盘占用量
2.加速启动速度
AOF重写触发机制
1.bgrewriteaof
2.AOF重写配置（同时满足配置文件中auto-aof-rewrite-percentage auto-aof-rewrite-min-size两个配置）
bgwriteaof命令
AOF重写流程
注：
aof_rewrite是在子进程执行，子进程带有主进程数据副本,不会阻塞客户端请求
子进程在AOF重写期间,主进程依然需要会记录数据变化日志，就会出现当前数据与AOF重写之后的数据不一致
解决方案：
redis增加了一个aof_rewrite_buf(aof重写缓冲区),当主进程fork出子进程后开始启用,此时主进程需要将日志同时记录到aof_buf(aof缓冲区)与aof_ewrite_aof(aof重写缓冲区),当子进程重写完数据后给主进程发送信号,此时 主进程通过信号处理函数将aof_rewrite_buf数据追加到新aof文件后，替换旧aof文件
5.混合持久化
重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。AOF在重写(aof文件里可能有太多没用指令，所以aof会定期根据内存的最新数据生成aof文件)时将重写这一刻之前的内存rdb快照文件的内容和增量的 AOF修改内存数据的命令日志文件存在一起，都写入新的aof文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换；
AOF根据配置规则在后台自动重写，也可以人为执行命令bgrewriteaof重写AOF。 于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。
相关配置：
#redis 4.0引入
# 是否开启混合持久化
aof-use-rdb-preamble yes
6.总结
①redis存在AOF与RDB两种持久化方式
如果redis宕机或重启时想要恢复数据,会优先采用哪种方式恢复数据呢？
AOF与RDB同时开启时,会优先使用AOF恢复数据,如果采用RDB恢复数据,可以先将AOF关闭,appendonly no,重启完成后，执行config set appendonly yes动态开启AOF
