Redis 持久化

持久化定义：把内存中的数据存放到硬盘当中

把内存中的数据存入到硬盘中有两种方式：RDB（快照）和AOF（append only file）

RDB：

redis默认使用RDB，在路径var/lib/redis下输入ll可以看到

使用rm -rf dump.rdb在目录把该快照删除，便于测试如何生成快照。
这时打开一个redis用来当客户端，运行BGSAVE ，就会重新生成快照。

除了BGSAVE以外SAVE也可以生成快照。

BGSAVE和SAVE的区别：
BGSAVE ：使用fork创建父进程的副本，子进程，让子进程来把数据存到磁盘中，主线程继续处理客户端请求。（如果创建好子进程之后，父进程没有接受到来自客户端的set请求。子进程的存储速度会非常快，父子进程各占一半的内存；如果创建好子进程之后，父进程接收到了来自客户端的set请求，那么父进程就会占用较多的内存保证来自客户端的set请求不会丢失。子进程占内存较少，存储速度会稍慢一些。）
SAVE ：停止客户端处理请求，先运行把数据存到磁盘中，再开始处理客户端请求。

以上是手动触发快照，快照也可以在服务器中配置触发条件。

这里快照的触发条件为：
60秒内发生10000次改变时
300秒内发生10次改变时
900秒内发生1次改变时

最后一种快照生成方式：
在服务端使用Shutdown指令（停止所有客户端）时，会使用save生成一次快照

快照RDB怎么丢失数据：
在上次保存save和下一次保存save之间客户端对服务端发起了n个请求，但是此时突然断电宕机，那么这个区间中的n个请求将会丢失。

AOF：

redis默认关闭AOF，需要在配置文件中找到，并开启。

AOF的存储路径就与RDB存储路径同步。

AOF的触发条件是当客户端进行写操作后生成日志
使用两个命令页面，一个打开.aof文件，一个做测试。
测试增：

测试删：

测试改：

由此得出添加删除修改日志中都会存在对应的记录。

测试的出来的一些结论：
RDB：先删除再改数据，会自动生成一个文件。相当于重新生成，顶掉前面的快照。
AOF：删除aof文件之后，需要重启redis再生成，服务端进行写操作，不会自动生成文件，在一个.aof文件中一条一条往下记录。

AOF日志追加频率：

三种方法：
always：
一条一条同步到磁盘
优点：服务端发生意外时将损失减到最少
缺点：影响redis速度，降低硬盘寿命

everysec：
每秒进行一次同步，把一秒内的所有写操作同步到磁盘
优点：没有always的缺点
缺点：在服务端发生以外的时候会损失一秒以内的数据。
性价比更高，redis推荐使用

no：操作系统决定何时同步
优点：不会影响redis性能
缺点：服务端发生意外会丢失不定量的数据。如果用户硬盘处理速度慢，就会导致redis堵塞，造成redis速度变慢

AOF重写机制：

当AOF文件过大时，非常占内存，这时就需要对AOF进行重写，会创建一个新的AOF文件。看着是把原AOF文件中冗余的命令去除，重新生成。其实是将数据库内容用命令的方式重写了一遍。  上图中两行代码表示，当第一次重写AOF文件时，文件大于64mb时进行重写。当再重写的时需要同时 1、满足当前AOF文件大于64mb 2、占内存量达到上一次重写之后的一倍。

举个简单的例子
现在AOF占用内存达到64mb，进行重写，重写后为20mb。再次重写时要大于64mb且大于40mb，当前例子中就是当文件大于64mb时进行重写。

小总结

RDB：占用磁盘空间少，恢复数据所需要的时间少，若出现宕机情况，会丢失上一次快照到宕机这一时间段中的数据。

AOF：占用磁盘空间多，恢复数据所需要的时间长，若出现宕机情况，会丢失大约一秒内的数据。