在上篇文章《Linux安装Redis》中我们已经成功地在Linux服务器上安装好了redis，并且也能正常使用redis存取数据了。那这时有一个问题，如果我们的redis发生故障宕机了会发生什么事情？我们都知道，redis的数据是存储在内存中的，并没有存储在磁盘上，这也是redis性能高的主要原因。所以，如果redis宕机了，那redis中的数据也会消失，这就可能导致我们的数据发生丢失。显然，这并不是我们希望的结果。那怎样解决呢？那就是对redis中的数据进行持久化。

redis的持久化方式有两种：RDB和AOF。

RDB

RDB的实现方式为，在指定时间将当前时刻内存中的数据生成一个快照文件（.rdb文件，默认为dump.rdb），并将这个快照文件保存到磁盘上。这样，即使redis宕机了，下次重启时也可以通过读取这个快照文件来恢复数据。

rdb文件默认文件名为dump.rdb，是在配置文件中配置的如果我们想要修改这个名字可以修改下面的配置：

触发生成rdb快照文件的方式主要有五种：配置文件自动触发、执行save命令、执行bgsave命令、执行shutdown命令、执行flushall命令。

1.配置文件自动触发

redis默认的配置文件redis.conf中，有一个自动触发rdb持久化的配置：

这三行配置默认是被注释掉的，使用时可以根据自己的需求按规则来配置。这三行命令的意思是：

save 3600 1 -> 3600秒内有1个key被修改，则触发RDB

save 300 100 -> 300秒内有100个key被修改，则触发RDB

save 60 10000 -> 60秒内有10000个key被修改，则触发RDB

当满足其中任意一个save条件时，都会触发一次bgsave命令进行异步持久化。

2.执行save命令

save命令是一个同步操作，执行该命令后，RDB持久化是在主进程中进行的，这样会阻塞当前redis服务，直到RDB持久化完成后，客户端才能正常连接redis服务。

3.执行bgsave命令

bgsave命令是对save命令的一个优化，是一个异步操作。执行该命令后，redis主进程会通过fork操作创建一个子进程，RDB持久化是由子进程操作，完成后自动结束。这个过程中，主进程不阻塞，可以继续接收客户端的访问。因此，redis内部所有涉及RDB持久化的操作都是采用的bgsave方式，save命令基本已经废弃。

bgsave的流程可以参考下图：

4.执行shutdown命令

这种触发方式比较简单，只需要在客户端执行shutdown命令即可：

5.执行flushall命令

flushall命令是清空redis内存中的数据，并且同时清空dump.rdb文件。所以这个命令就相当于删库跑路，此处只是说明该命令会触发rdb，实际使用中千万不要执行。

如果之前没有dump.rdb文件，则执行flushall命令后，会生成一个dump.rdb文件：

如果之前已经存在dump.rdb文件，并且里面也存在数据，那么执行flushall命令后，会将原来dump.rdb文件中的内容清空。此处我们验证一下：

首先我们先向redis中设置三个key，然后通过bgsave命令触发rdb：

虽然看不懂，但也能看到我们刚才设置的key和value的值。然后，再执行flushall命令，再次查看dump.rdb文件的内容：

发现我们之前设置的三个key-value已经被清空了。

AOF

AOF是redis提供的另一种数据持久化方式，它会记录客户端对redis服务端的每一次写操作，并将这些写操作以redis协议追加保存到后缀为aof的文件末尾。在redis服务器重启时，会读取并加载aof文件，达到恢复数据的目的。

aof持久化方式redis是默认不开启的，我们可以通过配置文件开启aof持久化方式：

appendonly的值默认为no，改为yes即可开启aof持久化方式。AOF的默认文件名为appendonly.aof，也可通过appendfilename配置修改。

AOF的三种写入策略

redis配置文件中有三种写入策略：

1. appendfsync always

客户端对redis服务器的每次写操作都写入AOF日志文件。这种方式是最安全的方式，但每次写操作都进行一次磁盘IO，非常影响redis的性能，所以一般不使用这种方式。

2. appendfsync everysec

每秒刷新一次缓冲区中的数据到AOF文件。这种方式是redis默认使用的策略，是考虑数据完整性和性能的这种方案，理论上，这种方式最多只会丢失1秒内的数据。

3. appendfsync no

redis服务器不负责将数据写入到AOF文件中，而是直接交给操作系统去判断什么时候写入。这种方式是最快的一种策略，但丢失数据的可能性非常大，因此也是不推荐使用的。

AOF文件重写

既然AOF是通过日志追加的方式来存储redis的写指令，那么当我们对同一个key做多次写操作时，就会产生大量针对同一个key操作的日志指令，导致AOF文件会变得非常大，恢复数据的时候会变得非常慢。因此，redis提供了重写机制来解决这个问题。redis通过重写AOF文件，保存的只是恢复数据的最小指令集。

我们可以通过下面命令手动触发重写：bgrewriteaof。

也可以通过配置文件自动触发重写：

auto-aof-rewrite-percentage 100：当文件的大小达到原先文件大小（上次重写后的文件大小，如果没有重写过，那就是redis服务启动时的文件大小）的两倍。

auto-aof-rewrite-min-size 64mb：文件重写的最小文件大小，即当AOF文件低于64mb时，不会触发重写。

只有这两个指标同时满足的时候才会发生重写。

AOF文件的重写流程如下：

（1）bgrewriteaof触发重写，判断是否存在bgsave或者bgrewriteaof正在执行，存在则等待其执行结束再执行；

（2）主进程fork子进程，防止主进程阻塞无法提供服务；

（3）子进程遍历Redis内存快照中数据写入临时AOF文件，同时会将新的写指令写入aof_buf和aof_rewrite_buf两个重写缓冲区，前者是为了写回旧的AOF文件，后者是为了后续刷新到临时AOF文件中，防止快照内存遍历时新的写入操作丢失；

（4）子进程结束临时AOF文件写入后，通知主进程；

（5）主进程会将上面的aof_rewirte_buf缓冲区中的数据写入到子进程生成的临时AOF文件中；

（6）主进程使用临时AOF文件替换旧AOF文件，完成整个重写过程。

整个过程可以参考下图：

某些场景下，AOF文件格式可能会发生错误，导致redis不能识别里面的数据，例如文件写到一半宕机了，或者人为不小心编辑了AOF文件内容等等。针对这种情况，redis提供了一个命令来解决这种异常：redis-check-aof --fix appendonly.aof。在执行该命令之前，最好先备份一下原AOF文件，以防万一。

比如，我们配置AOF文件写入策略为appendfsync everysec，然后写一些数据到redis中。此时，我们发现已经生成appendonly.aof这个文件了：

此时，我们编辑这个文件，将最后的“$5”修改为“$测试”：

保存后，重启redis服务，然后查看redis日志：

发现启动失败，说是文件格式错误，让使用redis-check-aof --fix命令修复AOF文件。我们执行这个命令：

成功修复后，我们再看我们的AOF文件内容：

发现少了一些数据，说明修复过程会造成部分数据的丢失。此时我们再启动redis服务，并查看里面的数据：

RDB和AOF对比

RDB的优点：

1. RDB文件非常紧凑，节省内存空间；
2. RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快；
3. 适合全量备份、全量复制的场景，经常用于灾难恢复（对数据的完整性和一致性要求相对较低的场合）

RDB的缺点：

1. 服务器宕机时，可能会丢失部分数据；
2. 每次保存RDB的时候，Redis都要fork出一个子进程，这个过程是阻塞的，如果数据集巨大，那阻塞的时间就会很长。

AOF的优点：

1. 数据更加完整，丢失数据的可能性较低；
2. AOF日志文件可读，并且可以对AOF文件修复。

AOF的缺点：

1. AOF日志记录在长期运行中逐渐庞大，恢复起来非常耗时，需要定期对AOF日志进行瘦身处理；
2. 恢复备份速度比较慢。

实际使用中，如何选择redis的持久化方式呢？可以看下redis官网的说法：

关注我，一起学习，一起进步！