Redis持久化机制

 温馨提示：本文所涉及操作都是围绕单进程单实例版（单机版）Redis，文中有关于Redis配置文件路径等需按自己个人服务器实际路径为准 ！！或根据[Redis单机版详细安装图文教程](https://blog.csdn.net/weixin_44977377/article/details/123343579?spm=1001.2014.3001.5501)一文重新安装一个干净的环境来操作~

Redis持久化机制

RDB

配置参数释义save / bgsave弊端优点Redis Forck AOF

优点弊端方案分析

Redis VS HDFS

HDFSRedis AOF配置

开启AOFfsync策略

Redis执行快照/副本时是怎么保证非阻塞对外提供服务的同时实现将数据落地的？

Redis数据落地的时候具有时点性在某一个时间点开始数据落地的时候，程序通过fork的方式创建一个子进程，当主进程数据发生修改后，每一笔修改会触发写时复制（COW），新的数据指向新的内存地址，子进程中的落地数据还是指向老的数据地址，因此，子进程落地的数据还是创建的时候的数据，保证了时点正确。

save : 关机维护时使用，会阻塞服务bgsave : fork创建子进程，不会阻塞服务 弊端

不支持拉链，只有一个dump.rdb，通常需要人工维护每天拷贝出最后一份rdb数据

丢失数据相对多一些，时点与时点之间窗口数据容易丢失，比如8点得到一个rdb, 当9点需要要落一个rdb,服务器宕机了

类似java中的序列化，恢复的速度相对快

使用linux的时候,父进程的数据，子进程可不可以看得到？

理论上进程是数据隔离的！但父进程其实可以让子进程看到数据！比如linux中,export的环境变量，子进程的修改不会破坏父进程,父进程的修改也不会破坏子进程

速度快空间小

Append only File （只会向文件追加）Redis中，RDB和AOF可以同时开启

如果开启了AOF，只会用AOF恢复

v4.0 后变化

AOF中包含RDB全量，增加记录新的写操作

丢失数据少 弊端

文件体量无限变大，恢复慢 方案分析

Redis运行了N（假设N>=10）年，开启了AOF，N年初刚过完年，Redis突然挂了,新的一年整个人都不好了，问：

1、AOF多大？

很大，假设有10T

2、恢复时，内存不会溢出？

不会，因为要溢出N年前就溢出了，而且溢出的数据根本不会成功写到文件中

3、恢复要多久？

恢复最快且至少N/2年

既然如此，什么方案才能既保住AOF丢失数据量少的优点，又要让AOF足够小?

Redis VS HDFS HDFS

Fsimage+edits.log

让日志只记录增量合并的过程 Redis

v4.0以前

重写

删除抵消的命令合并重复的命令 最终也是一个纯指令的日志文件 v4.0以后

重写

将老数据RDB到AOF文件中将增量的以指令形式Append到AOF

AOF是一个混合体

利用了RDB的快利用了日志的全量

有这样一个配置项【aof-use-rdb-preamble yes】

原文描述：

当重写AOF文件时，Redis可以在AOF文件中使用RDB的前导来更快地重写和恢复。
当这个选项被打开时，重写的AOF文件由两个不同的节组成:

【RDB文件】【AOF尾巴】

当加载时，Redis识别AOF文件以“Redis”字符串开始，然后加载带有前缀的RDB文件，并继续加载AOF尾部。

编辑配置文件

vi /etc/redis/6379.conf 

找到APPEND onLY MODE 部分配置文件

将appendonly no 修改为appendonly yes

自动AOF

自动重写只追加文件。当AOF日志大小增长指定的百分比时Redis能够自动重写日志文件隐式调用BGREWRITEAOF指令。

自动AOF是怎样工作的？
Redis记住最近一次重写后AOF文件的大小(如果在重启后没有重写，则使用启动时AOF文件的大小)。将此基础大小与当前大小进行比较。如果当前大小大于指定的百分比，则会触发重写。您还需要为要重写的AOF文件指定最小大小，这对于避免重写AOF文件时，即使达到了百分比增长，但它的实际大小却很小。

Redis支持三种不同的模式

默认值是“everysec”

no:不进行fsync，让操作系统在需要的时候更快的刷新数据.Always:每次写入追加日志后进行fsync。速度较慢但是数据是最安全可靠的。Everysec:每秒fsync一次。基于两者之间的折中速度和数据安全的一种模式。