Redis中两种持久化机制RDB和AOF

前提:

      随着redis越来越流行，使用者不在仅仅满足其只是一个内存数据库，同时也期望其能将内存数据落磁盘，
      这样重启服务就不会导致缓存数据丢失了
      
Redis还为我们提供了持久化的机制，分别是RDB(Redis DataBase)和AOF(Append Only File)。

模式	说明	优点	缺点
RDB	定期将redis当前内存数据快照备份到硬盘	redis重启时恢复速度快	由于备份不宜频繁，会导致系统异常宕机时，redis大量数据丢失
AOF	将redis执行的命令每隔1s批量同步到文件中	机器异常宕机时，最多丢失1s数据	由于保存的是命令，会导致保存很多赘余数据，文件过大(这时候恢复起来相对rdb会慢很多)

持久化模式

一 : RDB

1: RDB 的持久化思路
获取当前内存快照并将快照数据保存到磁盘实现当前数据全量备份

2.RDB 持久化难点

a- 如何获取当前内存数据快照
redis利用linux fork子进程后( cow机制:https://juejin.im/post/5bd96bcaf265da396b72f855 )
子进程拥有父进程的内存快照来获取内存快照

b-保存数据落盘时io操作阻塞其他请求
redis rdb持久化落盘操作只在独立的子进程中进行不会影响到主进程中的其他请求

python解析rdb文件的办法: https://blog.csdn.net/FloatDreamed/article/details/103720986
注意rdb文件储存位置: https://blog.csdn.net/liangpingguo/article/details/105364427

3-触发机制

(1)rdb持久化为redis开启的默认持久化方式，可通过配置文件灵活配置，默认如下

save 900 1          //15分钟内有一条数据写入时触发rdb持久化
save 300 10        //5分钟内有10条数据写入时触发rdb持久化
save 60 10000     //1分钟内有10000条数据写入时触发rdb持久化

(2)除了默认触发之外，我们也可以通过redis客户端发送命令主动触发rdb持久化，具体命令如下：

>save          //主进程执行rdb持久化操作
>bgsave      //生成后台进程执行rdb持久化(默认方式)

4.rdb持久化数据安全性

疑问: rdb持久化模式下，当机器宕机，会丢失多少数据？
答: 从最近一次rdb保存到宕机时的数据都会丢失

二: AOF

1.aof持久化核心思路

将服务器收到的更新命令直接写入文件尾部，恢复时直接重放文件中命令即可

2.aof持久化难点

(1)aof文件由于赘余数据，会变得很庞大(占用磁盘空间、重启load数据变慢) redis会定期重写aof文件(下文中会详细介绍)，抛弃赘余

(2)保存数据到aof文件落盘时io操作阻塞其他请求 redis aof文件写入在主线程，
   比较耗时的刷盘操作(fsync)则由专门的异步线程来处理，保证主线程不被io阻塞

3. 触发条件
redis默认不开启aof持久化方式，可通过修改如下配置开启

	appendonly yes #yes开启no关闭

aof持久化刷盘频率控制

	appendfsync always  //每次命令都刷盘
	appendfsync everysec //每秒刷盘一次(默认)
	appendfsync no  //从不刷盘，由内核去刷盘

4.aof持久化对redis性能影响

疑问: aof持久化涉及磁盘io操作(write数据到aof文件)，那么该操作是否会严重影响redis吞吐量?

答: 在aof文件追加过程中，write调用是在redis主线程内，而fsync(将文件数据从内核缓存区buffer中真正写入磁盘)控制刷盘却是在一个独立的后台线程中来完成，所以并不需要担心开启aof会十分影响redis性能

5.aof文件重写

(1)aof重写解决的问题

aof文件重写是为了解决aof命令添加持久化模式下，会有大量赘余命令(比如设置一个k-v，之后又删除)导致aof文件过大。
不仅浪费系统资源(主要是磁盘)，而且会导致load数据到内存重放变慢

(2)aof重写核心原理

aof重写过程会有大量io操作，所以redis会像写rdb文件一样为其分配一个独立的进程去执行重写。
重写的过程中redis会将新完成的命令写入一段临时buf。当aof重写完成，将buf中的命令数据批量写入aof文件中

我们知道aof重写是去掉赘余命令(例如先增加后删除)，如果通过原文件内容去逐一进行逻辑计算找出赘余必然会耗费大量计算和存储资源。
redis是通过直接将当前内存k-v数据拼装成命令协议格式并写入aof文件，如此便十分优雅的去掉原aof文件中的赘余命令

(3)aof重写客户端触发命令:

	bgrewriteaofCommand

6 aof持久化的安全性

疑问: aof持久化模式下，机器宕机，最多丢失多少数据

答:aof根据appendfsync配置的不同，丢失数据情况分别如下:

模式	说明	数据安全级别	最大丢失数据
always	每次写入都刷盘	高	宕机过程中那次epoll事件循环中的已完成命令的更新数据
everysec	每s刷盘一次	中	最多丢失2s数据
no	从不刷盘，刷盘工作完全交于操作系统来完成	低	无法准确评估

• 对于always参数，由于刷盘并不是每次更新命令都执行一次，而是一次epollwait触发后只批量执行一次。故其也会丢失数据

• everysec虽然是每s执行一次刷盘，理论上最大丢失1s数据，但是由于在刷盘过程中有个特殊逻辑，当某次刷盘前，判断刷盘线程已在工作(处理之前的刷盘任务)，则本次刷盘延后2s。故该模式下最大丢失其实是2s的数据量

• no啥时候刷盘，完全有内核管理，对应用系统来说存在很大的不确定性，故很难评估其数据安全性

rdb持久化在恢复过程中会比aof快很多么？

rdb在恢复过程中会优于aof文件。
事实也的确如此，因为aof文件中会存在大量赘余命令，当然会恢复的慢。

但是不要忘了，aof文件可是会定期重写(刚重写后同样没赘余)的，
如果是刚重写后不久的aof文件，那么其恢复就不会相对rdb慢很多了(理论分析)。

所以可以说只要我们重写aof的频次不低，那么aof恢复就不怕他相较rdb有明显的速度差异