Redis学习（二）----Redis持久化

Redis持久化选项

Redis提供两种不同的持久化方法来将内存中的数据存储到硬盘中。一种方法叫快照，另外一种方法叫只追加文件。将内存中的数据存储到硬盘的一个主要原因是为了之后重用数据，或者为了防止系统故障而将数据备份到一个远程位置。

一、快照持久化

1、快照持久化的概念

快照持久化，也叫RDB持久化，RDB是Redis用来进行持久化的一种方式，是把当前内存中的数据集快照写入磁盘，也就是 Snapshot 快照（数据库中所有键值对数据）。恢复时是将快照文件直接读到内存里。

2、创建快照的方法

①、bgsave，客户端通过redis客户端发送BGSAVE命令来创建快照。对于支持BGSAVE命令的平台来说，Redis会调用fork来创建一个子进程，然后子进程负责将快照写入硬盘，而父进程继续处理请求命令。

②、save，save命令不常用，该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。

③、当redis通过shutdown命令关闭服务器的时候，服务器关闭前会执行save命令，阻塞所有的客户端，不再执行客户端发送的任何命令，并在执行完save命令后关闭服务器。

④、如果用户在redis服务器的配置文件配置了save配置选项，例如：save 60 1000 ，那么从redis最近一次创建快照开始，当60秒内有1000次写入，触发redis执行BGSAVE命令，进行快照持久化。

⑤、当一个redis服务器连接另外一个redis服务器，并且收到对方发送的SYNC命令开始一次复制操作的时候，如果主服务器没有执行BGSAVE命令，那么主服务器会执行BGSAVE命令，触发快照持久化。

3、快照持久化的结果

一般的，快照持久化的结果是在配置文件中指定的dir路径下生成一个后缀为.rdb的文件。例如：dump.rdb.

4、快照持久化恢复数据

将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可，redis就会自动加载文件数据至内存了。Redis 服务器在载入 RDB 文件期间，会一直处于阻塞状态，直到载入工作完成为止。

5、快照持久化的优势和劣势

①、优势

1、RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集。这种文件非常适合用于进行备份和灾难恢复。

2、生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

3、RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

②、劣势

1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，属于重量级操作(内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑)，频繁执行成本过高(影响性能)

2、RDB文件使用特定二进制格式保存，Redis版本演进过程中有多个格式的RDB版本，存在老版本Redis服务无法兼容新版RDB格式的问题(版本不兼容)

3、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改(数据有丢失)

二、只追加文件

1、只追加文件的概念

只追加文件持久化也称AOF持久化， AOF 则是通过保存Redis服务器所执行的写命令来记录数据发生状态。

2、开启AOF持久化的方法

开启的AOF持久化主要是通过配置文件中指定配置来开启，在redis,conf文件中有如下配置：

①、appendonly：默认值为no，也就是说redis 默认使用的是rdb方式持久化，如果想要开启 AOF 持久化方式，需要将 appendonly 修改为 yes。

②、appendfilename ：aof文件名，默认是"appendonly.aof"

③、appendfsync：aof持久化选项以及同步频率：

• no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快，但是不太安全；
• always表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低；
• everysec表示每秒执行一次fsync，可能会导致丢失这1s数据。通常选择 everysec ，兼顾安全性和效率。

通常为了兼顾数据安全和写入性能，用户使用appendfsync everysec选项，让redis以每秒一次的频率对AOF文件进行同步。

2、重写和压缩AOF文件

由于AOF持久化是Redis不断将写命令记录到 AOF 文件中，随着Redis不断的进行，AOF 的文件会越来越大，文件越大，占用服务器内存越大以及 AOF 恢复要求时间越长。为了解决这个问题，Redis新增了重写机制，当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令 bgrewriteaof 来重写。

AOF文件重写并不是对原文件进行重新整理，而是直接读取服务器现有的键值对，然后用一条命令去代替之前记录这个键值对的多条命令，生成一个新的文件后去替换原来的 AOF 文件。

AOF文件重写触发机制：通过 redis.conf 配置文件中的 auto-aof-rewrite-percentage：默认值为100，以及auto-aof-rewrite-min-size：64mb 配置，也就是说默认Redis会记录上次重写时的AOF大小，默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。

AOF重写原理：fork子进程进行AOF文件的重写，子进程进行 AOF 重写期间，服务器进程（父进程）可以继续处理其他命令。使用子进程而不是子线程，目的是为了保证数据的安全性。

3、AOF持久化的优劣之处

优势：

• AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。
• AOF 文件使用 Redis 命令追加的形式来构造，因此，即使 Redis 只能向 AOF 文件写入命令的片断，使用 redis-check-aof 工具也很容易修正 AOF 文件。
• AOF 文件的格式可读性较强，这也为使用者提供了更灵活的处理方式。例如，如果我们不小心错用了 FLUSHALL 命令，在重写还没进行时，我们可以手工将最后的 FLUSHALL 命令去掉，然后再使用 AOF 来恢复数据。

劣势：

• 对于具有相同数据的的 Redis，AOF 文件通常会比 RDB文件体积更大。
• 虽然AOF提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。但在 Redis 的负载较高时，RDB 比 AOF 具好更好的性能保证。
• RDB 使用快照的形式来持久化整个 Redis 数据，而 AOF 只是将每次执行的命令追加到 AOF 文件中，因此从理论上说，RDB 比 AOF 方式更健壮。官方文档也指出，AOF 的确也存在一些 BUG，这些 BUG 在 RDB 没有存在。