带你彻底理解 Redis 持久化

带你彻底理解 Redis 持久化

一、前言

作为内存数据库，在我们后端开发中应用是非常多的，尤其是在大流量背景下，redis作为缓存数据库就必不可少了。想了解使用场景可以移步至redis使用场景。

作为内存数据库，就会存在一个致命的问题，比如宕机、停电、自然灾害等等导致停止服务，那么内存中的数据就会丢失，对于不重要的数据还好，但是一旦涉及到核心数据，这个是万万不能接受的。为此，也为我们提供了两种持久化方式，和持久化，既然两种持久化方式是同时提供给我们，想必这两种方式是有共存的必要性的。

请大家和我一起认识下这两个大兄弟吧~

二、RDB

RDB概念

是一种快照存储持久化方式，也就是Snapshot快照，就是将某一时刻的内存数据保存到硬盘的文件当中，默认保存的文件名为，是一个二进制文件，而在服务器启动时，会重新加载文件的数据到内存当中恢复数据。

RDB 持久化开启

持久化方式开启有两种，一种是自动开启，一种是手动开启；

1、手动开启

（1） 命令

命令是一个同步操作，在执行持久化操作的时候，会阻塞进程，其他客户端的命令会被阻塞直到同步完成。

注意：由于命令阻塞进程，如果数据量太大，会造成阻塞，在此期间所有的命令都收不到，所以此命令慎用！

（2）命令

命令是一个异步操作，执行该命令的时候会一个新的子进程，子进程将数据保存到文件之后，子进程才会退出。

注意：执行命令的时候，只有在才会阻塞进程其他客户端；一般进程的操作是很快的。

2、自动开启

自动开启，我们需要先看下的配置，打开配置文件，查看标签如下：

大概做一个简单的简介：

这种通过服务器配置文件触发的方式，与命令类似，达到触发条件时，会forks一个子进程进行数据同步；

RDB 文件生成过程

生成临时文件，并写入数据。

完成数据写入，用临时文代替代正式文件。

删除原来的文件。

三、AOF

以日志的形式记录每一个写操作,将执行过的所有写指令记录下来（读操作不记录），只许追加文件不可以改写文件，启动之后会读取文件来实现重新恢复数据，完成恢复数据的工作。

开启AOF

模式是关闭的，开启需要我们去在配置文件中打开；

这里做一个大概的解释：

写入策略

会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。

上面配置文件中，介绍了三种配置策略：

:每修改同步，每一次发生数据变更都会持久化到磁盘上，性能较差，但数据完整性较好。

: 每秒同步，每秒内记录操作，异步操作，如果一秒内宕机，有数据丢失。

:不会主动调用去将日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次，将缓冲区中的数据写到磁盘上。

重写

随着运行时间的增长，执行的命令越来越多，会导致文件越来越大，当文件过大时，会执行重写机制来压缩文件。

重写触发方式：

1、手动执行 触发重写

2、在文件中配置开启重写，

当符合一定的条件时就会触发重写机制，默认：

重写过程：

从主进程中出子进程，并拿到时的文件数据写到一个临时文件中

在重写过程中，收到的命令会同时写到缓冲区和重写缓冲区中，这样保证重写不丢失重写过程中的命令

重写完成后通知主进程，主进程会将缓冲区中的数据追加到子进程生成的文件中

会原子的将旧文件替换为新文件，并开始将数据写入到新的文件上

数据恢复

当开启时，启动时会优先载入文件来恢复数据；只有当关闭时，才会载入文件恢复数据。

如果出现异常损坏，我们可以使用命令：进行修复；

四、一较高下

前面介绍了和这两种持久化方式，想必他们基本的特性和优缺点都有一定的掌握，我们进行归纳总结下：

RDB

优点：

与方式想比，数据恢复更快

数据进行备份的时候，使用子进程，对性能影响较小

文件比较紧凑，适合做数据备份

缺点：

使用save命令会造成服务器阻塞，直接数据同步完成才能接收后续请求

当服务器宕机的时候，会出现一段时间内数据丢失

当使用数据备份的时候，进程会短暂的阻塞进程，同时出来的进程也会占一部分内存；

AOF

优点：

可以更好的保护数据不丢失，一般会以每隔1秒，如果进程挂掉，最多丢失1秒的数据。

以的模式写入，所以没有任何磁盘寻址的开销，写入性能非常高。

日志文件的命令通过非常可读的方式进行记录，如果操作失误，比如输入，可以再中删除该命令，进行数据恢复；

缺点：（1）对于同一份文件文件比数据快照要大。（2）数据恢复比较慢。