Redis RDB持久化和AOF持久化

目标：什么是RDB持久化、AOF持久化

Redis的持久化方式

Mysql的Mysqldump文件和Redis的dumo.rdb类似（原理并不一致）

Mysql的redo log和Redis的AOF(appendonly.aof)类似（原理并不一致）

可以关联记忆

PS：如果觉得阅读太长，可以直接阅读优点和缺点。

通常数据库存在三种用于持久操作以防止数据损坏的常见策略：

是数据库不关心故障，而是在数据文件损坏后从数据备份或快照中恢复。RDB就是这种情况
该数据库使用操作日志记录每个操作的操作行为，以在失败后通过日志恢复一致性。由于操作日志是按顺序追加写入的，因此不会出现无法恢复操作日志的情况。类似于Mysql的重做和撤消日志。
数据库不修改旧数据，而仅通过追加进行写入，因此数据本身就是日志，因此永远不会出现数据无法恢复的情况。CouchDB是一个很好的例子。AOF类似这种情况

严格上讲Redis为持久化提供了三种方式：

RDB：在指定的时间间隔能对数据进行快照存储，类似于MySQL的dump备份文件。
AOF：记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据（MySQL的binlog）。
RDB与AOF混合使用，这是Redis4.0开始的新特性。在混合使用中AOF读取RDB数据重建原始数据集，集二者优势为一体。

RDB持久化

Redis配置文件

 # redis.conf
# 放行访问IP限制
bind 0.0.0.0
# 后台启动
daemonize yes
# 日志存储目录及日志文件名
logfile "/usr/local/redis/log/redis.log"
# rdb数据文件名
dbfilename dump.rdb
# rdb数据文件和aof数据文件的存储目录
dir /usr/local/redis/data
# 设置密码
requirepass 123456

开启RBD

我们可以配置Redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置（这3个选项都屏蔽，则RDB禁用）：

 # redis.conf
# 900秒内如果超过1个key改动，则发起快照保存
save 900 1
# 300秒内如果超过10个key改动，则发起快照保存
save 300 10
# 60秒内如果超过1W个key改动，则发起快照保存
save 60 10000

什么叫Redis快照

快照，顾名思义可以理解为拍照一样，把整个内存数据映射到硬盘中，保存一份到硬盘，因此恢复数据起来比较快，把数据映射回去即可，不像AOF，一条条的执行操作命令。

快照是默认的持久化方式。这种方式就是将内存中的数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。

产生快照的情况有以下几种：

执行bgsave命令（此时Redis会fork一个子进程，子进程负责生成硬盘文件，父进程负责继续接受命令）
执行save命令（和bgsave命令不同，发送save命令后，系统创建快照完成之前系统不会再接受任何新的命令，换句话说save命令会阻塞后面的命令，而bgsave不会）
根据用户在配置文件中配置的快照触发时间执行（即配置文件中的save 900 1）
客户端发送shutdown，系统会先执行save命令阻塞客户端，然后关闭服务器
当有主从架构时，从服务器向主服务器发送sync命令来执行复制操作时，主服务器会执行bgsave操作

RDB工作原理

Redis默认会将快照文件储存在Redis当前进程的工作目录中的dump.rdb文件中，可以通过配置dir和dbfilename两个参数分别指定快照文件的储存路径和文件名。流程过程如下图。

Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）。
父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件。
当子进程写入完所有数据后会用该临时文件（子进程生成的文件）替换旧的RDB文件，至此一次快照操作完成。

在执行fork的时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父进程共享同一内存数据，父进程要更改其中某片数据时（如执行一个写命令），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的RDB文件存储的是执行fork一刻的内存数据。

写时复制策略也保证了在fork的时刻虽然看上去生成了两份内存副本，但实际上内存的占用量并不会增加一倍。这就意味着当系统内存只有2GB，而Redis数据库的内存只有1.5GB时，执行fork后内存使用量并不会增加到3GB（超出物理内存）。为此需要确保Linux系统允许应用程序申请超过可用内存（物理内存和交换分区）的空间，方法是在/etc/sysctl.conf文件加入vm.overcommit_memory = 1 ，然后重启系统或者执行sysctl vm.overcommit_memory = 1 确保设置生效。

另外需要注意的是，当进行快照的过程中，如果写入操作较多，造成fork前后数据差异较大，是会是的内存使用量显著超过实际数据大小的，因为内存中不仅保存了当前数据库的数据，而且还保存着fork时刻的内存数据。进行内存用量估算时很容易忽略这一个问题，造成内存用量超限。

通过上述过程可以发现Redis进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说任何时候RDB文件都是完整的。这使得我们可以通过定时备份RDB文件来实现Redis数据库备份。RDB文件是经过压缩（可以通过配置rdbcompression参数以禁用压缩节省CPU占用）的二进制格式，所以占用的空间会小于内存中的数据大小，更加利于传输。

Redis启动后会读取RDB快照文件，将数据从硬盘载入到内存。根据数据量大小与结构和服务器性能不同，消耗的时间也不同，通常将一个记录1000万个字符串类型键、大小为1GB的快照文件载入到内存中需要花费约20~30秒。

扩展：写入时复制（Copy-on-write，简称COW）是一种计算程序设计领域的优化策略。其核心思想是，如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，知道某个调用者试图修改资源的内容时，系统才会真正的复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这个过程对其他的调用者都是透明的。此做法主要的优点是如果调用者没有修改该资源，就不会有副本（private copy）被创建，因此多个调用者只是读取操作时可以共享同一份资源。

RDB的优点

一旦采用RDB方式，那么你的整个Redis数据库将只包含一个紧凑压缩的二进制文件，这对于文件备份而言是非常完美的。比如，你可能打算每小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据源。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行回复。
对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它的存储介质上。
性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程。之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务器进程执行IO操作了。
相比于AOF机制，如果数据集很大，RDB的启动效率会更高。

RDB的缺点

如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前数据没来得及写入磁盘的数据都将丢失。
由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

AOF持久化

它也是Redis持久化的重要手段之一，AOF（Append Only File）只追加文件，也就是没吃处理完请求命令后都会将此命令追加到AOF文件的末尾、而RDB是压缩成二进制等时机开子进程去干这个事情。

Redis配置文件

 # redis.conf
# 默认appendonly为no
appendonly yes
appendfilename "appendonly.aof"
# RDB文件和AOF文件所在目录
dir /usr/local/redis/data
# fsync 持久化策略
appendfsync everysec
# AOF重写期间是否禁止fsync；如果开启该选项，可以减轻文件重写时CPU和硬盘的负载（尤其是硬盘），但是可能会丢失AOF重写期间的数据；需要在负载和安全性之间进行平衡
no-appendfsync-on-rewrite no
# 当前aof文件大于多少字节后才触发
auto-aof-rewrite-min-size 64mb
# 当前写入日志文件的大小超过上一次rewrite之后的文件大小的百分之100时，也就是2倍时触发Rewrite
auto-aof-rewrite-percentage 100
# 如果AOF文件结尾损坏，Redis启动时是否仍载入AOF文件
aof-load-truncated yes

同步策略

Redis中提供了三种AOF同步策略：

每秒同步（默认，每秒调用一次fsync，这种模式新能并不是很糟糕）
每修改同步（会极大削弱Redis的性能，因为这种模式下每次write后都会调用fsync）
不主动同步（由操作系统自动调度刷磁盘，性能是最好的）

 # redis.conf
# 每秒钟同步一次，该策略为AOF的缺省策略
appendfsync everysec

# 每次有数据修改发生时都会写入AOF文件
appendfsync always

# 从不同步。高效但是数据不会主动被持久化
appendfsync no

事实上，每秒同步也是异步完成的，其实效率也是非常高的，所以差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。

而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。

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

AOF工作原理

client

→

Redis Server

→

执行命令

→

命令写入AOF缓冲区

→

刷新磁盘写入AOF文件

AFO的频率高的话肯定会对Redis带来性能影响，因为每次都是刷盘操作。跟Mysql一样了。Redis每次都是先将命令放到缓冲区，然后根据具体的策略（每秒/每条指令/缓冲区满）进行刷盘操作。如果配置的always，那么就是典型阻塞，如果ererysec每秒的话，那么会开一个同步的线程区每秒进行刷盘操作，对主线程影响稍小。

写入文件与恢复

AOF文件是一个只进行append操作的日志文件，因此在写入的过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。假如一次操作只是写入了一半的数据就出现了系统崩溃问题，不用担心，在Redis下次启动之前，我们可以通过redis-check-aof工具来帮助我们修复问题。

AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被人读懂，对文件进行分析（parse）也很轻松。

导出（export）AOF文件也非常的简单，举个例子，如果你不小心执行了“FLUSHALL”命令，但只要AOF文件未被重写，那么只要停止服务器，移除AOF文件最末尾的“FLUSHALL”命令，并重启Redis，就可以将数据集恢复到“FLUSHALL”命令执行之前的状态。

重写

Redis可以在AOF文件体积变得过大时，自动地在后台对AOF进行rewrite。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。

因为Redis在创建新的AOF文件的过程中，会继续将命令追加到现有的AOF文件里面，即使重写的过程中发生停机，现有的AOF文件也不会丢失。

而一旦新的AOF文件创建完毕，Redis就会从旧AOF文件切换到新的AOF文件，并开始对新的AOF文件进行追加操作。

为什么要重写

比如我有业务很简单，就来回delete set 同一个key。就这个业务运行了10年，那么aof文件将记录无数个delete k1， set k1 xxx。其实都是重复的，但是我aof每次都追加，文件变成了1T大小。这时候Redis宕机了，要恢复，你想想1TB大小的aof文件去恢复，累死了。最主要的是1TB大小只记录了两个命令，所以压缩其实就是来处理这件事的。

rewrite触发条件

客户端执行“bgrewriteaof”命令
auto-aof-rewrite-min-size 64 mb # 当前aof文件大于多少字节后才触发
auto-aof-rewrite-percentage 100 # 当前写入日志文件的大小超过上一次rewrite之后的文件大小的百分之100时，也就是2倍时触发Rewrite

AOF优点

使用AOF会让你的Redis更加耐久，你可以使用不同的fsync策略，无fsync，每秒fsync，每次写的时候fsync，使用默认每秒fsync策略，Redis的性能依然很好（fsync是由后台线程进行处理的，主线程会尽力处理客户端请求）一旦出现故障，你最多丢失1 秒的数据。
AOF文件是一个只进行追加的日志文件，所以不需要写入seek，即使由于某些原因（磁盘空间已满，写的过程中宕机等等）未执行完整的写入命令，你也可以使用redis-check-aof工具修复这些问题。
Redis可以在AOF文件体积变得过大时，自动的在后台对AOF进行重写。重写过后的新AOF文件包含了恢复当前数据集所需的最小命令集合。整个重写操作是绝对安全的，因为Redis在创建新的AOF文件的过程中，会继续将命令追加到现有的AOF文件里面，即使重写的过程中发生停机，现有的AOF文件也不会丢失。而一旦新的AOF文件创建完毕，Redis就会从旧的AOF文件切换到新的AOF文件，并开始对新的AOF文件进行追加操作。
AOF文件有序地保存了对数据库执行的所有写入操作，这些写入操作以Redis协议的格式保存，因此AOF文件的内容非常容易被读懂，对文件镜像分析（parse）也很轻松。导出（export） AOF 文件也非常简单：举个例子，如果你不小心执行了 FLUSHALL 命令，但只要 AOF 文件未被重写，那么只要停止服务器，移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis ，就可以将数据集恢复到 FLUSHALL 执行之前的状态。