用于学习后的自己总结，如有错漏恳请指教
持久化概念
持久化就是将内存中的数据模型转化为存储模型，然后存储模型转化为内存中的数据模型是一个可逆的过程。其中数据模式可以指任何的数据结构和对象模型，存储模型可以是磁盘文件、xml、二进制流等等。
redis要持久化理由
目前这么流行redis作为缓存其中一点就是因为redis数据存放在内存中所以操作起来比存在磁盘的数据来的快，不用寻址之类的。但这也相对有问题就是当redis服务器宕机后数据是不像mysql数据会有保存数据而是数据会丢失，所以为了数据能长时间保存就需要持久化。有人会问，redis只是做缓存服务器宕机后数据没有了直接去数据库查询然后再次缓存到redis即可，对于这个个人理解的是这么操作的话如果缓存数据不多其实也没毛病，但redis缓存的数据有时候不在服务器上面有可能是根据某种计算得出的所以主服务器又要承受计算一遍，假若缓存数据过多redis服务器重启后大量发起对数据库的查询这样对数据库的压力会增加有可能导致缓存雪崩（雪崩可以看我另一个文章）
redis两种持久化方式
1、数据快照：将当前所有的数据内容记录下来----RDB（恢复数据的时候按着整个文件存储的数据进行恢复）
2、数据日志：将数据操作指令流程记录下来，只记录会修改数据的指令例如set等操作，get这样的操作是不会记录的—AOF（恢复数据的时候按着指令一条一条执行）
RDB数据快照
触发RDB持久化方式：save、bgsave和配置文件（使用的也是bgsave）
解释：在学习阶段可以使用上述两个操作进行对比学习，但在上线阶段不推荐使用save操作，因为redis是一个单线程程序多个客户端在设置数据时候其中一个客户端发起了save操作，服务器接收到后会将save之后的操作都阻塞等到save完成操作后才继续执行。而bgsave指令则是会掉起一个fork函数生成子进程进行创建rdb文件
RDB优点
1.rdb文件是紧凑的二进制文件，存储效率高
2.内部存储是redis某个节点的数据快照，适合数据备份，全量复制等场景
3.恢复数据速度比aof快，因为是某节点全部数据直接恢复即可，aof还需要一条一条指令执行
4.应用：每x小时进行bgsave备份，用于灾难恢复
RDB缺点
1.无法做到实时持久化，有可能丢失数据，例如10点、11点备份一次，中间一小时数据可能丢失
2.bgsave需要执行fork函数创建子进程，需要牺牲掉一些性能
3.redis版本不同，未对RDB文件格式的版本统一，有可能出现版本数据不兼容情况（解决：例如存了2.0的rdb文件需要恢复到4.0上，先用2.0的服务器把数据存到相应的数据库例如mysql，然后再把数据放入4.0服务器中）
4.存储数据量大，因为是某个节点整个块进行存储，上次记录为10G，下次就是以10G为原型记录导致io时间过长
AOF数据日志
开启AOF持久化方式配置文件：
appendonly 是否开启AOF持久化
appendfsync AOF写策略
appendfilename 文件名
aof写数据时候，当客户端发来指令后先放到缓存区，然后到达某个程度时候写到.aof文件里面然后执行指令。其中某个程度有三种策略
always:每次都写入同步到AOF文件中，性能低，但数据零失误 但不建议使用
everysec(每秒)：每一秒同步一次，性能高，但有可能会丢失一秒内的数据
no（系统控制）：由操作系统控制，对于程序来说是不可控的。
AOF重写机制
因为命令不断的写入，文件会越来越大为了解决这个问题redis引入了AOF重写机制来压缩文件体积。重写机制就是将同一个数据的操作指令执行结果转化成最终结果数据对应的指令记录。重写规则是：进程内已超时数据不再写入（数据没有了）、 忽略无效指令（例如对name这个key进行了三次的set name = ‘1’,set name = ‘2’ ,set name =‘3’ 。前两次已经没有意义所以重写机制会只记录最后一步set name = '3’即可）、对同一数据多次操作指令（lpush a 1,lpush a 2 修改为 lpush a 1 2）
AOF和RDB比较
| 持久化方式 | RDB | AOF |
|---|---|---|
| 占用存库空间 | 小（数据及压缩） | 大（指令级重写） |
| 储存速度 | 慢 | 快 |
| 恢复速度 | 快 | 慢 |
| 数据安全性 | 会丢失数据（按照设置的时间间隔，在间隔区间数据可能丢失） | 依据策略(always，everysec) |
| 资源消耗 | 高/重量级 | 低/轻量级 |
| 启动优先级 | 低 | 高 |