1、redis的持久化方式
通常数据库存在三种用于持久操作以防止数据损坏的常见策略：
- 是数据库不关心故障，而是在数据文件损坏后从数据备份或快照中恢复。rdb就是这种情况
- 该数据库使用操作日志记录每个操作的操作行为，以在失败后通过日志恢复一致性。由于操作日志是按顺序追加写入的，因此不会出现无法恢复操作日志的情况。类似于mysql的重做和撤消日志。
- 数据库不修改旧数据，而仅通过追加进行写入，因此数据本身就是日志，因此永远不会出现数据无法恢复的情况。couchdb是一个很好的例子。aof类似这种情况
严格上讲redis为持久化提供了三种方式：
- rdb：在指定的时间间隔能对数据进行快照存储，类似于mysql的dump备份文件。
- aof：记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据（mysql的binlog）。
- rdb与aof混合使用，这是redis4.0开始的新特性。在混合使用中aof读取rdb数据重建原始数据集，集二者优势为一体。redis的持久化方式
2、快照(snapshot)
2.1、什么叫redis快照
快照，顾名思义可以理解为拍照一样，把整个内存数据映射到硬盘中，保存一份到硬盘，因此恢复数据起来比较快，把数据映射回去即可，不像aof，一条条的执行操作命令。
快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。
2.2、快照生成方式
产生快照的情况有以下几种：
-
执行bgsave命令(此时redis会fork一个子进程,子进程负责生成硬盘文件,父进程负责继续接收命令)
-
或执行save命令(和bgsave命令不同，发送save命令后，系统创建快照完成之前系统不会再接收任何新的命令，换句话说save命令会阻塞后面的命令，而bgsave不会)
-
根据用户在配置文件中配置的快照触发时间执行
-
客户端发送shutdown，系统会先执行save命令阻塞客户端，然后关闭服务器
-
当有主从架构时，从服务器向主服务器发送sync命令来执行复制操作时，主服务器会执行bgsave操作
2.3、rdb工作原理
redis默认会将快照文件存储在redis当前进程的工作目录中的dump.rdb文件中，可以通过配置dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。流程过程如下（rdb.c中）。
-
redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；
-
父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；
-
当子进程写入完所有数据后会用该临时文件替换旧的 rdb 文件，至此一次快照操作完成。
在执行 fork 的时候操作系统（类 unix 操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻父子进程共享同一内存数据，当父进程要更改其中某片数据时（如执行一个写命令），操作系统会将该片数据复制一份以保证子进程的数据不受影响，所以新的rdb文件存储的是执行fork一刻的内存数据。
写时复制策略也保证了在 fork 的时刻虽然看上去生成了两份内存副本，但实际上内存的占用量并不会增加一倍。这就意味着当系统内存只有2 gb，而redis数据库的内存有1.5 gb时，执行 fork后内存使用量并不会增加到3 gb（超出物理内存）。为此需要确保 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万个字符串类型键、大小为1 gb 的快照文件载入到内存中需要花费20～30秒。
扩展：写入时复制（英语：copy-on-write，简称cow）是一种计算程序设计]领域的优化策略。其核心思想是，如果有多个调用者（callers）同时请求相同资源（如内存或磁盘上的数据存储），他们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本（private copy）给该调用者，而其他调用者所见到的最初的资源仍然保持不变。这过程对其他的调用者都是透明的。此作法主要的优点是如果调用者没有修改该资源，就不会有副本（private copy）被创建，因此多个调用者只是读取操作时可以共享同一份资源。
2.4、rbd的优点
- 一旦采用rdb方式，那么你的整个redis数据库将只包含一个紧凑压缩的二进制文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。
- 对于灾难恢复而言，rdb是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
- 性能最大化。对于redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行io操作了。
- 相比于aof机制，如果数据集很大，rdb的启动效率会更高。
2.5、rdb的缺点
- 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么rdb将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。
- 由于rdb是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，fork子进程可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。
3、aof持久化
它也是redis持久化的重要手段之一，aof（append only file）只追加文件，也就是每次处理完请求命令后都会将此命令追加到aof文件的末尾。而rdb是压缩成二进制等时机开子进程去干这件事。
3.1、特点
这种方式可以将所有客户端执行的写命令记录到日志文件中,aof持久化会将被执行的写命令写到aof的文件末尾,以此来记录数据发生的变化,因此只要redis从头到尾执行一次aof文件所包含的所有写命令,就可以恢复aof文件的记录的数据集。
3.2、开启aof
通过配置进行启动，默认是关闭的，以下是 aof 常用配置：
# 默认appendonly为no aof持久化开启
appendonly yes
# aof文件名称
appendfilename "appendonly.aof"
# rdb文件和aof文件所在目录
dir /usr/local/redis/data
3.3、同步策略
redis中提供了3种aof同步策略：
-
每秒同步（默认，每秒调用一次 fsync，这种模式性能并不是很糟糕）
-
每修改同步（会极大消弱 redis 的性能，因为这种模式下每次 write 后都会调用 fsync）
-
不主动同步（由操作系统自动调度刷磁盘，性能是最好的）
# 每秒钟同步一次，该策略为aof的缺省策略
appendfsync everysec
# 每次有数据修改发生时都会写入aof文件
appendfsync always
# 从不同步。高效但是数据不会主动被持久化
appendfsync no
事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。
而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。
至于无同步，redis不会主动去将aof日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。
3.4、aof工作原理
aof的频率高的话肯定会对redis带来性能影响，因为每次都是刷盘操作。跟mysql一样了。redis每次都是先将命令放到缓冲区，然后根据具体策略（每秒/每条指令/缓冲区满）进行刷盘操作。如果配置的always，那么就是典型阻塞，如果是everysec每秒的话，那么会开一个同步线程去每秒进行刷盘操作，对主线程影响稍小。
3.5、写入文件与恢复
aof 文件是一个只进行append操作的日志文件，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。假如一次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们修复问题。
aof 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 redis 协议的格式保存， 因此 aof 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。
导出（export） aof 文件也非常简单： 举个例子， 如果你不小心执行了 flushall命令， 但只要 aof 文件未被重写， 那么只要停止服务器， 移除 aof 文件末尾的 flushall命令， 并重启 redis ， 就可以将数据集恢复到 flushall 执行之前的状态。
3.6、重写
redis 可以在 aof 文件体积变得过大时，自动地在后台对 aof 进行rewrite。即redis以append模式不断的将修改数据写入到老的磁盘文件中，同时redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。
因为 redis 在创建新 aof 文件的过程中，会继续将命令追加到现有的 aof 文件里面，即使重写过程中发生停机，现有的 aof 文件也不会丢失。
而一旦新 aof 文件创建完毕，redis 就会从旧 aof 文件切换到新 aof 文件，并开始对新 aof 文件进行追加操作。
3.6.1、为什么要重写
比如我有业务很简单，就来回delete set 同一个key。就这个业务运行了10年，那么aof文件将记录无数个delete k1， set k1 xxx。其实都是重复的，但是我aof每次都追加，文件变成了1t大小。这时候redis宕机了，要恢复，你想想1tb大小的aof文件去恢复，累死了。最主要的是1tb大小只记录了两个命令，所以压缩其实就是来处理这件事的。
3.6.2、rewrite触发条件
-
客户端执行
bgrewriteaof命令 -
auto-aof-rewrite-min-size 64mb # 当前aof文件大于多少字节后才触发
-
auto-aof-rewrite-percentage 100 # 当前写入日志文件的大小超过上一次rewrite之后的文件大小的百分之100时，也就是2倍时触发rewrite
3.7、常用配置
# 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
3.8、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 执行之前的状态。
3.9、aof缺点
aof文件恢复数据慢
- 对于相同数量的数据集而言，aof文件通常要大于rdb文件。rdb 在恢复大数据集时的速度比 aof 的恢复速度要快。
aof持久化效率低
- 根据同步策略的不同，aof在运行效率上往往会慢于rdb。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和rdb一样高效。
4、持久化总结
两种持久化方案既可以同时使用(aof),又可以单独使用,在某种情况下也可以都不使用,具体使用那种持久化方案取决于用户的数据和应用决定。
无论使用aof还是快照机制持久化,将数据持久化到硬盘都是有必要的,除了持久化外,用户还应该对持久化的文件进行备份(最好备份在多个不同地方)。