Redis持久化方式

RDB方式

image.png

、
RDB的含义就是将redis数据做一个快照创建一个RDB二进制文件存在硬盘上，如果redis宕机了，下次启动时候就可以从这个硬盘上读取到内存中，RDB默认名字叫dump.rdb。

RDB的触发方式三种

1.save(同步)；
2.bgsave(异步)；
3.自动

第一种save流程图

image.png

对redis执行一个save命令，如果数据量比较大，会让redis阻塞。此时会影响线上环境。

第二种 bgsave流程图

image.png

对redis执行一个bgsave命令，使用Linux的一个fork()函数，创建一个redis的子进程 创建RDB，如果创建成功会向redis返回bgsave successfully,通常fork()函数是很快的，但是也有慢的时候。会阻塞redis主进程.

第三种自动生成RDB流程

image.png

在redis配置文件中配置方式，如 save 60 10000,表示在60秒的时间内数据如果改变了1万次那么就调用bgsave命令，生成RDB文件，这样方式可能会生成RDB频率很高，所以不建议使用。

RDB方式缺点：
非常的耗时，因为需要将所有的数据文件同步进磁盘，这是一个O(N)的过程；
Fork()是一个copy-on-write的操作，还有IO写到磁盘是很消耗性能的。

2.AOF持久化方式

类似于写日志的方式，当对redis执行一条命令，将会同步到AOF文件

image.png

AOF有三种方式：
第一种always,意思就是每次执行一条redis命令都会同步到AOF文件；

image.png

第二种everysec。指每秒种都同步一次redis的缓冲区到AOF文件；

image.png

第三种no，依靠操作系统来实现，操作系统什么时候刷进AOF随操作系统；

image.png

三种对比：

image.png

关于AOF重写

有时候比如我们对redis进行如下操作：
假如key刚开始是0，我们进行incr（原子递增）达到了一亿次，此时key的值就等于一亿，但是此时在AOF文件当中，也会有一亿次的操作，实际等价与incrby（一亿），将这个一亿次的incr操作优化成Incrby（一亿）就是AOF的重写。

AOF的重写方式：
方式一：1.使用bgrewriteaof命令
此redis发送一条bgrewriteaof，redis会返回ok，然后fork一条子进程去AOF重写
（**注意这里AOF重写不是真的重写AOF文件，而是从redis内存中进行重写）

image.png

方式二：配置文件的方式，底层也是采用上面的命令。

AOF流程解析：

image.png

redis收到命令之后会fork一个子进程去重写新的AOF文件，而主进程依然可以运行，
如3-1，就是正常的AOF操作，此时主进程也会生成一个aof_rewrite_buf，然后追加到新的AOF文件，最后一步新的AOF文件会替代旧的AOF文件。