Redis持久化
官网：https://redis.io/docs/manual/presistence
RDB（Redis DataBase）
RDB持久性以指定的时间间隔执行数据集的时间点快照
实现类似照片记录效果的方式，就是把某一时刻的数据和状态以文件的形式写到磁盘上，也就是
快照。这样一来即使故障宕机，快照文件也不会丢失，数据的可靠性也就得到了保证。
这个快照文件就称为RDB文件(dump.rdb)，其中，RDB就是Redis DataBase的缩写。
使用RDB的优势？
- 适合大规模的数据恢复
- 按照业务定时备份
- 对数据完整性和一致性要求不高
- RDB文件在内存中的加载速度要比AOF快得多
使用RDB的劣势？
在一定间隔时间做一次备份，如果redis意外挂掉了，就会丢失从当前到最近一次快照期间的数据，快照之间的数据会丢失
内存数据的全量同步，如果数据量太大会导致I/O严重影响服务器性能
RDB依赖于主进程的fork，在更大的数据集中，可能会导致服务请求的瞬间延迟。fork的时候内存中的数据被克隆了一份，大约两倍的膨胀性，需要慎重考虑
怎么检查和修复RDB？
redis-check-rdb rdbfilename
自动触发
修改myredis下的redis.conf，添加save 5 2，每五秒触发两次修改，并且修改rdb默认保存路径为自定义的/myredis/dumpfiles，保存的文件名修改为dump6379.rdb
在五秒内改动两条数据
在dumpfiles文件夹自动创建dump6379.rdb文件
如何恢复？
将备份文件（dump.rdb）移动到redis安装目录并启动服务即可
备份成功后用flushdb清空redis看看是否可以恢复数据
- 结论：执行FLUSHALL/FLUSHDB命令也会产生dump.rdb文件，但里面是空的，没有意义
- 下次启动的时候redis会自动从dump.rdb文件中自动读取上一次备份的数据
物理恢复，一定服务器和备份分机隔离
手动触发
redis提供了两个命令来生成RDB文件：save和bgsave
save
在主程序中执行会阻塞当前redis服务器，知道持久化工作完成，执行save命令期间，redis不能处理其他命令，在实际工作中禁止使用
将dumpfiles里的rdb文件删掉
添加一条键值对，并且手动save
此时dumpfiles里就会创建一个备份的rdb文件
bgsave
redis会在后台异步进行快照操作，不阻塞快照的同时还可以响应客户端的请求，该触发方式会fork一个子进程，由子进程复制持久化过程
redis默认会使用bgsave对当前内存中的所有数据快照，这个操作是子进程在后台完成的，这就允许主进程同时可以修改数据
fork？
类似git里从当前主分支拉取代码但是不影响主分支的修改
在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但是子进程在此后都会exec系统调用，出于效率考虑，尽量避免膨胀
lastsave
可以通过lasrsave命令获取最后一次成功执行快照的时间
使用data -d @时间戳的方式解析时间戳
AOF（Append Only File）
是什么？
- 以日志的形式来记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，即，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
- 默认情况下redis是没有开启AOF的，开启AOF需要设置配置：appendonly yes
AOF持久化流程
AOF缓冲区三种写回策略
- Always：同步写回，每个写命令执行完立刻同步地将日志协会磁盘
- exerysec：每秒写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，每隔1秒把缓冲区中的内容写入磁盘
- no：操作系统控制的写回，每个写命令执行完，只是先把日志写到AOF文件的内存缓冲区，由操作系统决定何时将缓冲区内容写回磁盘
总结
| 配置项 | 写回时机 | 优点 | 缺点 |
|---|---|---|---|
| Always | 同步写回 | 可靠性高，数据基本不丢失 | 每个写命令都要落盘，性能影响很大 |
| Everysec | 每秒写回 | 性能适中 | 宕机时丢失一秒内的数据 |
| No | 操作系统控制的写回 | 性能好 | 宕机时丢失数据较多 |
启动AOF
- 将redis.conf里面的appendonly no改成yes
- 写操作继续，生成aof文件到指定的目录
AOF文件保存名称
- base基本文件
- incr增量文件（写操作命令会被记录在这个文件里面，不记录读操作命令）
- manifest清单文件
正常恢复
正常重启的时候redis就会从aof中将命令全部读回来
异常恢复
故意乱写正常的AOF文件，模拟网络闪断文件写error
重启redis之后就会进行AOF文件的载入（无法启动）
异常修复命令：
redis-check-aof --fix进行修复
优势
- 有不同的fsync策略：根本不，每秒fsync，每次查询时fsync。fsync是使用后台线程执行的，当没有fsync正在进行时，主线程将努力执行写入，因此只会丢失一秒钟的写入
- AOF日志是一个仅附加日志，因此不会出现寻道问题，也不会再断电时出现损坏问题，即使由于某种原因（磁盘已满或其他原因）日志以写一半的命令结尾，redis-check-aof工具也可以进行修复
- 当AOF变化太大时，redis能够在后台重写aof。重写是完全安全的，因为当redis继续附加到旧文件时，会使用创建当前数据集所需的最少操作集生成一个全新的文件，一旦第二个文件准备就绪，redis就会切换两者并开始附加到新的那一个
劣势
- 相同数据集的数据而言，aof文件要远远大于rdb文件，恢复速度也慢于rdb文件
- aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率与rdb相同
AOF的重写机制
由于AOF持久化是redis不断将写命令记录到AOF文件中，随着redis不断进行，AOF文件会越来越大（文件越大，占用服务器内存越大以及AOF恢复要求时间越长）
为了解决上述问题redis新增的重写机制，即：当AOF文件的大小超过所设定的峰值时，redis就会自动启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，或者可以手动使用命令bgrewtiteaof来重写
触发机制
- 自动触发
- 满足配置文件中的选项后，redis会记录上一次重写时的AOF大小，默认配置时当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时
- 手动触发
- 客户端向服务器发送bgrewriteaof命令
重写机制的原理
- 在重写开始前，redis会创建一个“重写子进程”，这个子进程会读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中
- 同时主进程会将数据接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样是保证原有的AOF文件的可用性，避免在重写过程中出现意外
- 当“重写子进程”完成重写工作后，它会给父进程发一个信号，当父进程接收到信号后就会将内存中缓存的写指令追加到新AOF文件中
- 追加结束后，redis就会用新的AOF文件来代替旧的AOF文件，之后再有新的写指令，就会追加到新的AOF文件中
- 重写AOF文件的操作，并没有读取旧的AOF文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的AOF文件，类似于快照
总结
RDB+AOF混合持久化
当RDB和AOF同时启用的时候，会优先使用AOF，如果没有AOF再使用RDB
同时开启两种持久化方式
- 在这种情况下，当redis重启的时候会优先载入AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整
- RDB的数据不实时i，同时使用两者时服务器重启也只会AOF文件。（保留RDB以防万一）
纯缓存模式
关闭RDB+AOF：
save ""：禁用RDB，禁用的时候仍然可以使用save、bgsave生成rdb文件appendonly no：禁用AOF，禁用的时候仍然可以使用bgrewriteaof生成aof文件
