Redis持久化的两个方向
什么是持久化方向1、保存数据（快照）——RDB方向2、记录过程（日志）——AOF RDB
save指令手动完成RDBbgsave指令手动完成RDB
bgsave的工作流程 save指令配置自动完成RDB三种RDB实现方式的对比RDB的优缺点 AOF
AOF的概念AOF写数据的过程启动AOF相关配置AOF手动重写机制AOF自动重写机制AOF重写流程 RDB和AOF的区别
Redis持久化的两个方向 什么是持久化利用永久性存储介质将数据进行保存，在特定的时间将保存的数据进行恢复的工作机制称为持久化持久化。
用于防止数据的意外丢失，确保数据安全性
对于Redis，就是将内存中的数据，保存到硬盘（外存）的过程
将当前数据状态进行保存，快照形式，存储数据结果，存储格式简单，关注点在数据。其实就是原封不动的保存某一时刻的数据。
将数据的操作过程进行保存，日志形式，存储操作过程，存储格式复杂，关注点在数据的操作过程。。例如idea中，使用ctrl+z可以撤回操作，恢复之前的数据，这背后就有对日志的记录
使用方法：直接在向redis注入数据后，输入save指令即可
注意事项：由于redis是单线程的处理模式，所有的指令到达redis服务器之后都以指令队列的形式等待被执行，所以——save指令的执行会限塞当前Redis服务器，直到当前RDB过程完成为止，有可能会造成长时间阻塞，线上环境不建议使用。
上面提到过，当数据量过大时，单线程的特点会造成效率低下，于是提出了bgsave来改善这一现象。
bgsave中的bg代表background，即后台。bgsave表示后台保存
使用方法和save类似，也是在向redis注入数据后，直接输入bgsave指令即可。
由于bgsave优化了save指令的阻塞问题，实际生产用bgsave要多得多。即：bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。
由linux中的fork函数创建出来子进程完成后续的持久化操作，子进程的阻塞将不会干扰主进程的运行，因此解决了save指令的阻塞问题
save的自动执行是主流的配置方案，通过设置自动持久化的条件，满足限定时间范围内key的变化数量达到指定数量即进行持久化。
格式：save second changes
语义：在多少秒（second）内发生多少次变化（changes），就自动完成持久化。
参数：second用于监控时间范围，changes用于监控key的变化量
注意：通过配置完成的自动save，后台执行的仍然是bgsave指令
由于配置完成的自动save指令的实质也是bgsave，因此实际上只有save和bgsave两种实现方法
RDB的优缺点 AOFRDB存储的弊端：
1、存储数据量较大，效率较低，基于快照思想，每次读写都是全部数据，当数据量巨大时，效率非常低
2、大数据量下的IO性能较低
3、基于fork创建子进程，内存产生额外消耗
4、宕机带来的数据丢失风险
解决以上问题的思路：
1、不写全数据，仅记录部分数据
2、降低区分数据是否改变的难度，改记录数据为记录操作过程
3、对所有操作均进行记录，排除丢失数据的风险
于是我们便得到了AOF持久化——
AOF（append only file）持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据产生的变化
AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式
AOF写数据的过程 启动AOF相关配置注意：和RDB不同的是，AOF默认是不开启的状态，需要我们手动开启
AOF有三种写数据的策略
分别是always、everysec、no
always：每次写入操作都会同步到aof文件，保证数据零误差，但是一性能较低，不建议使用
everysec：每秒将缓冲区的指令同步到aof文件中，最坏的情况是丢失一秒内的数据。准确性较高，同时保证了性能，建议使用（默认配置）
no（系统控制）：由操作系统控制每次同步到aof的周期，不可控
需要注意的是，aof只会记录对数据有影响的操作。
AOF手动重写机制重写的概念：随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干个条命令执行结果转化成最终结果数据对应的指令进行记录。（相当于只记录一连串指令最终一步到位的结果）
说白了就是缩减指令的过程
重写的作用：
·降低磁盘占用量，提高磁盘利用率
·提高持久化效率，降低持久化写时间，提高IO性能
·降低数据恢复用时，提高数据恢复效率
重写规则（了解）
1、进程内具有时效性的数据，并且数据已超时将不再写入文件
2、非写入类的无效指令将被忽略，只保留最终数据的写入命令。需要注意的是select指令虽然不更改数据本身，但是更改了数据的存储位置，这类命令同样需要记录
3、对同一数据的多条写命令合并为一条命令
手动重写的工作流程（和bgsave的流程极为相似）
基于everysec的重写流程
最后只会保存一份aof文件，从右边合并到左边，左边的aof文件更新后，右边的aof文件就会被删除
