[TOC]

1. Redis持久化

redis提供了多种持久化方式：

• none:没有使用任何持久化方式，当redis实例停止后，redis中的全部数据丢失。使用none就是将数据存储在内存和硬盘的临时文件中。
• RDB：快照模式，redis在间隔指定的时间间隔，对全部数据做快照，然后使用新的快照替换旧的快照。redis实例重启后，会直接按照最新的快照恢复数据。
• AOF：日志模式，redis将受到的全部的命令，按照一定的协议，存储进入日志文件。当日志文件达到一定的条件，redis会进行后台重写，保证AOF的日志文件不会太大。
• 混合模式：可以同时开启RDB和AOF模式，这样redis的所有操作都被记录，而且每隔指定的时间，都会做快照。redis在重启后，会优先使用AOF的日志文件进行恢复，因为AOF的日志记录的数据比RDB的快照文件记录的数据更加全面。

RDB只记录了某一时间点的数据。AOF记录了某一段时间的数据变化。

从时间上来说，RDB是一个时间点的数据，AOF是时间段的数据。

从行为上来说，RDB是静态记录数据，AOF是动态记录数据。

2. RDB 的优点

• RDB数据非常紧凑，它保存了某个时间点的全部数据，所以非常适合用于数据集的备份。
• RDB数据拥有全部数据，同时又很紧凑，所以，很方便将RDB文件从一个机器传输到其他机器。，适合灾难恢复。
• RDB在保存快照文件的时候，父进程会fork出一个子进程，接下来保存快照文件的全部工作由子进程来做，父进程不需要参与保存快照文件的过程，所以RDB持久化方式可以最大化redis性能。
• 与AOF相比，RDB在恢复大量数据的时候比较快。

3. RDB 的缺点

• RDB在运行的时候会造成少量数据的丢失：比如每隔1小时备份一次，那么在两次备份中间，redis宕机，在宕机与上次备份期间的数据全部丢失。
• RDB每次做快照，需要保存全部的数据，这是一个非常繁重的工作。而且99%的备份都不会使用到，但是却不能不做这个工作。(换句话说，当没有宕机时，这个工作没有价值；但是当出现宕机，这个工作的价值100%)
• RDB保存快照是交给子线程做的，当数据量比较大的时候，fork的过程就比较耗时，会造成fork时，轻微的卡顿(类似jvm的fill gc)。

4. AOF 的优点

• 使用AOF可以保证最全的数据：AOF可以配置fsync策略：无fsync，每秒fsync，写fsync。默认是每秒fsync的策略，表示每隔1秒就会将过去1秒的操作追加到AOF文件中。即使redis发生宕机，最多丢失1秒的数据。
• fsync是由后台进程完成的，对主线程几乎没有影响。
• AOF文件是一个只进行追加的日志文件，所以即使在追加的过程中发生宕机，也可以使用redis-check-aof工具进行修复。
• AOF文件重写：每当redis发生写入操作时，1秒后，这些操作就会被写入AOF文件中，那么随着时间的流逝，AOF会越来越大。当AOF增加到一定程度时，会触发redis重写操作。redis重写会只保留当前数据集的最小命令操作集。==比如 set x 7 ,set x 8等多条命令，只会保留最后一个。==在新的AOF创建完成之前，命令都是追加到原AOF文件中的，当原AOF重写成功，会切换到新的AOF文件，用新的AOF文件替换旧的AOF文件。
• AOF文件有序的保存了有效的写入操作，这些写入操作是以指定的协议进行保存的。所以即使发生异常操作，只要AOF还未被覆盖，那么将AOF文件中的异常命令移除，然后让redis进行恢复即可。(比如误操作flush all)

5. AOF 的缺点

• AOF文件的体积大于RDB文件的体积
• 根据使用的fsync的策略，AOF的速度可能慢于RDB。在一般情况下，每秒fsync的性能高，最坏情况下丢失的数据少。

6. 混合使用

如果想达到最高的数据安全性，应该同时使用两种策略。

如果能接受最短几分钟内的数据丢失，那么应该使用RDB。

7. 快照文件

在默认情况下，Redis将数据库快照保存在名字为fump.rdb的二进制文件中。可以对redis进行设置，实现只有redis的操作满足条件时才进行备份。

save 60 1000表示在60秒内，有1000个key发生了数据改动，才进行备份。

当然，也可以通过手动命令进行强行备份。

SAVE或者BGSAVE可以手动强行备份。

• 工作方式：

  redis需要保存dump.rdb时，会执行以下操作：

  1. forks子进程，redis同时有父进程和子进程
  2. 子进程将数据写入临时RDB文件
  3. 子进程完成RDB文件后，redis会用新的RDB文件替换旧的RDB文件，并删除旧的RDB文件。

  ==为什么使用fork==：在操作系统中，有一个优化机制是==写时复制==。就是说，fork子线程时，子线程持有的数据和父线程持有的数据是同一份，只有当子线程或者父线程需要写数据时，才会将子线程的数据从父线程拷贝一份。对于redis来说，fork出来的子线程没有写数据，只有读数据，所以，fork出来的子线程就不涉及数据的拷贝了，因为子线程和父线程使用同一份数据。在子线程拷贝期间，父线程会将期间受到的写操作放到内存缓冲中，到了时间才会将内存缓冲中的数据写入。==这也是为什么会丢失一小部分数据的原因。==

8. 日志文件

在配置文件中使用appendobly yes打开AOF持久化方式。

打开后，每当redis执行一个改变数据集的命令时，这个命令就会被追加到AOF文件的末尾。当redis被重启后，就会从AOF文件中读取命令，重新一次，就可以达到重建数据集的目的。

• 日志重建：

  因为AOF的方式是不断的将命令追加，所以，随着命令不断的被追加，AOF文件的体积也会越来越大。为了解决这个问题，redis可以在不打断服务端的情况下，对AOF文件进行重建(rebuild)。

  执行BGREWRITEAOF会生成一个新的AOF文件。

• fsync配置：

  每次有新的命令追加到AOF文件时，就调用fsync，将数据从内存缓冲写入磁盘：非常慢，非常安全.

  每秒一次fsync：足够快(和使用RDB持久化差不多)，并且最多丢失1秒钟的数据==类似配置RDB1秒钟备份一次，不过AOF不是全盘备份，而是增量备份.==

  从不fsync：将数据交给操作系统，操作系统认为内存缓冲区快满了，可以写入磁盘了，那么就进行写入。非常快，但是更不安全。

  (默认是每秒fsync，也是推荐的配置)

• AOF文件被损坏：

  为现有的AOF文件做个备份，然后使用redis-check-aof进行修复。最后重启redis，使用修复后的AOF文件恢复数据。

• 工作原理：

  AOF重写和RDB创建快照一样，巧妙的利用了写时复制：

  1. forks子进程，redis同时有父进程和子进程
  2. 子进程将新的AOF文件写入临时文件
  3. 在子线程写入的同时 ，如果有新的命令被执行，那么父进程会将命令同时存入内存缓冲区和原AOF文件==(这是为什么AOF数据比RDB丢失的少的多的多的原因)==，即使在重建 的过程中发生异常，原AOF文件也持有全部的命令，不会造成数据丢失(最多1秒)
  4. 子进程重写完成后，父进程将内存缓冲区的命令写入临时AOF文件，然后使用新的AOF文件替换原有的AOF文件。

9. RDB切换AOF

从RDB切换到AOF的步骤：

• 备份dump.rdb文件
• 执行redis-cli config set appendonly yes
• 执行redis-cli set save ""

执行的第一条命令开启了AOF功能，redis会阻塞，直到初始AOF文件创建完毕为止，之后redis会继续处理命令请求，并开始将写入命令追加到AOF文件末尾。

执行的第二条命令关闭了RDB功能，这一步可以省略，同时开启两种持久化方式。

==注意：需要记得在redis.conf文件中开启AOF功能，否则重启redis后，配置会被重置。==

10. RDB和AOF同时开启

在执行BGSAVE进行备份RDB文件时，不允许执行BGREWRITEAOF。当然，在执行BGREWRITEAOF时，也不允许执行BGSAVE。

防止两个redis后台同时对磁盘进行大量的IO操作。

如果BGSAVE正在执行，用户显式的调用BGREWRITEAOF命令，redis会向用户回复一个OK，告知用户，BGREWRITEAOF被预定执行，当BGSAVE执行完毕，就会执行BGREWRITEAOF。

当redis启动时，同时开启了RDB和AOF，那么redis会优先使用AOF进行回复数据，因为AOF文件保存的数据比RDB完整(通常情况下)。

11. redis数据备份

redis对于数据备份非常友好，你可以在任何时候对RDB备份文件进行拷贝：RDB文件一旦被创建就不会被修改==(只会进行替换)==。当服务器要创建一个新的RDB文件时，redis先会创建一个临时的RDB文件，当临时的RDB备份完成后，redis使用rename原子操作替换原有的RDB文件。

所以，任何时候，拷贝RDB文件都是绝对安全的。