＜学习笔记＞ Redis的持久化RDB / AOF

黑马笔记：

RDB：

        RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

快照文件成为RDB文件，默认是保存再当前运行目录。

怎么让Redis执行一下RDB呢？

        方式一：save  #  由Redis主进程来执行RDB，会阻塞所有命令（不推荐，适用于主动停止Redis进程）

        先使用redis-cli连接Redis，再执行save命令，就会执行RDB的备份操作了。但是该执行的操作是由Redis的主进程来完成的，我们知道Redis又是单线程的。一旦主进程来执行RDB，它就不能执行其他操作了，会阻塞所有命令。这时候如果有用户来执行操作，都没法执行。因为主进程在忙着执行RDB的，而RDB操作是需要把数据写到磁盘当中，而磁盘的IO往往是比较慢的。如果你的数据量比较大，这个过程就会耗时比较久。等待执行完成，才会返回一个OK，主进程才能去处理其他的请求。

        方式二：bgsave  #  开启子进程执行RDB，避免主进程受到影响（适用于在Redis执行的过程中去执行）

        在运行这个命令后，会立即返回一个Background saving started（开始后台保存），说明这个保存的命令是在后台异步执行的。

        bgsave几乎是0阻塞，为什么是几乎呢？因为把内存中的数据写入RDB的过程确实是异步执行的，但是子进程得来是需要fork主进程的，这个fork的过程是阻塞的，此时的主进程只能干这件事，不能执行用户的请求。（具体细节看黑马Redis98）

Redis停机时会执行一次RDB。

        Redis执行save操作，是在主动停机Redis的时候执行，但是如果我们的Redis服务器执行了一个月，没有来得及save，突然宕机了，数据就丢失了。所以，我们希望每隔一段时间，数据就备份一次。

所以在Redis的内部有触发RDB的机制，可以在配置文件中找到：

save 900 1    #  在900s内，如果至少有1个key被修改，则执行bgsave

save 300 10

save 60 1000

RDB的缺点：

        RDB执行间隔时间长，两次RDB之间写入数据有丢失的风险。

        fork子进程、压缩、写出RDB文件都比较耗时

AOF：

        AOF全称为Append Only File（追加文件，因为是不断地记录新的写操作命令，而不是像RDB一样每次都从头开始记录，所以叫追加文件）。Redis处理的每一个写命令都会记录在AOF文件中，可以看作是命令日志文件。

        AOF默认是关闭的，需要修改配置文件来开启AOF：

# 是否开启AOF功能，默认是no

appendonly yes

# AOF文件的名称

appendfilename "appendonly.aof"

        AOF的命令记录的频率也可以通过配置文件来配：

# 表示每执行一次写命令，立即记录到AOF文件

appendfsync always

# 写命令执行完先放入AOF缓冲区，然后表示每隔1s将缓冲区数据写到AOF文件，是默认方案

appendfsync everysec

# 写命令执行完先放入AOF缓冲区，由操作系统决定何时将缓冲区内容写回磁盘

appendfsync no

因为AOF记录的是写命令，RDB记录的是数据的值，一个key只能有一个值，但是一个key可以执行多个写的操作。多以AOF文件会币RDB文件大的多。 AOF记录同一个key的多次写操作，但只有最后一次写操作才有意义。通过执行bgrewriteaof命令，可以让AOF文件执行重写功能，用最少的命令达到相同效果。

Redis也会在触发阈值时自动去重写AOF文件。阈值也可以在配置中配置：

# AOF文件比上次文件增长超过多少百分比则触发重写

auto-aof-rewrite-percentage 100

# AOF文件体积最小多大以上才触发重写

auto-aof-rewrite-min-size 64mb

总结：

RDB和AOF各有自己的优缺点，如果对数据安全性要求较高，在实际开发中往往会结合两者来使用：