1 redis持久化（persistence）

1.1 Redis 提供了多种不同级别的持久化方式

RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。

Redis 还可以同时使用 AOF 持久化和 RDB 持久化。在这种情况下，当 Redis 重启时，它会优先使用 AOF 文件来还原数据集，因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。

也可以关闭持久化功能，让数据只在服务器运行时存在。

1.2 RDB 模式

1.2.1 配置方式

RDB 复制模式也称作快照模式，在指定时间间隔中保存数据快照。

save <seconds> <changes>

在 seconds 时间间隔中发生changes次数的变化，就触发一次快照保存。可以配置多条规则。

除了在redis的配置文件中配置快照的规则外，还可以手动直接触发一次快照。直接调用SAVE 或者 BGSAVE命令。

1.2.2 工作原理

当 Redis 需要保存 dump.rdb 文件时，服务器执行以下操作：

Redis 调用 fork() ，同时拥有父进程和子进程。
子进程将数据集写入到一个临时 RDB 文件中。
当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益

1.2.3 优缺点

优点：

RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。这种文件非常适合用于进行备份：比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心。
RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

缺点：

rdb模式按照指定时间发生几次变化来持久化数据，这就有可能在数据没有发生持久化的时候就宕机，导致当前时间段内的数据丢失
每次rdb回fork子进程进行，当数据量比较大的时候fork很耗时间，CPU紧张的时候更容易出现卡顿。

1.3 AOF(AppendOnly File) 模式

在服务器突然断电，死机，或者调用kill -9 命令杀死redis的时候，使用rdb的方式持久化是不够，这个时候最新的操作是没有被持久化。因此redis提供另外的一种持久化方式，append-only file 。

1.3.1 AOF 配置方式

要启动AOF的方式，需要在配置文件中设置

appendonly yes

配置时候，redis没产生一条指令都会被追加到AOF文件中，当服务器重启的时候，redis就从这个文件中重新执行指令来回复数据到内存中。

aof重写

通过上面不难发现，如果每次执行指令被保存，aof文件会越来远大。例如，一个increment 100次，就有100条指令，但是实际可以在回复数据的时候调用一句set 指令回复到最后的数据就可以了。所以redis也内置了重写机制。在不中断对客户端的服务器的情况下，在后台对aof文件重写。reids 2.2之前。需要是不是的调用BGREWRIETAOF指令，redis 2.4之后都是自动触发此指令。

同步频率配置 (how durable)

多久把数据同步(fsync)一次到文件的策略有三种：

fsync always 每次新的指令，每条指令都加到aof。此方法非常非常的慢，但是非常安全。
fsync everysec每个一秒钟同步一次。这种方法速度很快，最坏情况是损失1s内的数据
never no 不同步，而是交给操作系统去处理。非常快，但是不安全。

redis默认和推荐的方法是每秒同步方式。

配置方式：

# appendfsync always
appendfsync everysec
# appendfsync no

AOF文件损坏怎么处理

当AOF文件损坏的时候，redis不能再从AOF中恢复数据，可按找下面的步骤处理：

备份当前AOF文件
使用redis-check-aof工具修复原AOF文件，执行命令 redis-check-aof --fix
选择性的使用diff -u检测两个文件的不同
用修改后的文件重启服务

1.3.2 AOF 工作原理（rewrite）

redis forks 一个子进程
子进程开始把AOF写到一个临时文件
父进程计算所有的新变化并放在一个内存缓冲区（同时他还把这些变化写进老的AOF文件，所以重写失败，也是安全的）
最后。redis自动用新文件替换老文件。开始往新文件添加数据

1.3.3 AOF 优缺点

AOF 优点：

数据安全性更高，从同步机制上看。always方式满，但每条指令都存储。
aof是一个追加文件，出现问题可以使用redis-check-aof工具修复
文件过大的时候会使用重写方式，只要文件存在，数据有可以恢复
文件内容以redis的协议存储，方便解读。能偶方便导出和解析。

AOF 缺点：

数据量过大的时候，redis的aof体积会比rdb文件大
根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。在一般情况下，每秒 fsync 的性能依然非常高，而关闭 fsync 可以让 AOF 的速度和 RDB 一样快，即使在高负荷之下也是如此。不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）