一、redis持久化
1、RDB
RDB持久性以指定的时间间隔执行数据集的时间点快照
也就是说在一定的时间间隔内，将某一时刻的数据和状态以文件的形式写到磁盘上，这个快照文件交dump.rdb
Redis6更新策略
RDB手动触发
5秒2次修改
RDB手动触发
save:优先级高，执行该命令时其他进程都会停下来等这个命令执行完，因此在此期间redis对外缓存功能失效，很少用
bgsave:在执行该命令的时候，redis产生一个fork，相当于复制了一个父进程，由此来异步保存RDB
lastsave //查看上一次保存的时间戳，在linux下查看日期
优缺点
RDB修复命令
哪些操作会触发RDB快照
配置文件中默认的快照配置
手动 save/bgsave 命令
执行flush / flushdb 命令也会产生 dump.rdb 文件，但里面是空的，无意义
执行 shutdown 且没有设置开启 AOF 持久化
主从复制时，主节点自动触发
如何禁用快照
动态所有停止 RDB 保存规则的方法: redis-cli config set save “”
快照禁用
RDB优化参数
2、AOF
只记录写操作
AOF 持久化工作流程
AOF 缓冲区三种写回策略
always 同步写回，每个写命令执行完立刻同步地将日志写回磁盘
everysec (默认)每秒写回，每个写命令执行完，只是先把日志写到AOF缓冲区，每隔1s把缓存区地数据写入磁盘
no操作系统控制写回，只是将日志先写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
AOF功能配置
结果：当AOF文件破损后，redis启动都1启动不了
AOF文件异常修复
//命令： redis-check-aof --fix appendonly.aof.1.incr.aof
AOF的优缺点
AOF重写机制
自动配置
- 满足配置文件中的选项后，Redis会记录上次重写时地AOF大小
- 默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
- 手动配置
- 客户端向服务器发送 bgrewriteaof 命令
3、RDB+AOF混合
AOF默认是关闭的，当两者共存时，AOF的优先级高
同时开启两种持久化方式
当redis 重启时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。
那要不要只使用AOF呢
安特雷兹建议不要
因为RDB更适合用于备份数据库（AOF不断变化不好备份），留着AOF作为一个万一的手段
4、纯缓存模式
同时关闭RDB + AOF
save “”
禁用rdb
禁用db持久化模式下，我们仍然可以使用命令save、bgsave生成rdb文件
appendonly no
禁用aof
禁用aof持久化模式下，我们仍然可以使用命令 bgrewriteaof生成aof文件
