Redis 持久化策略

      Redis 中有两种持久化策略，分别为RDB和AOF。RDB全称为Redis DataBase，主要是在不同的时间点，将Redis某一时刻的数据生成快照存储在磁盘上（类似于VMware中的快照功能）；AOP全称为Append Only File，以追加的形式向磁盘上写入数据，对历史数据只追加而不修改。

      举个例子来说明Redis中这两种持久化策略的不同，假如我们做了新增、修改、删除这三个持久化操作，由于某种原因在内存中的所有数据被清除了，使用RDB对某一时刻的数据恢复，比如我们对删除操作做了快照节点，RDB不会关心前面的过程（新增及修改），而是直接恢复到最终的节点（删除）。而使用AOF是日志恢复，会对新增、修改、删除全部恢复。

      Redis中的两种持久化策略是可以同时存在，也可以同时取消的。如果同时存在，在数据恢复时，建议优先使用AOP，因为AOP恢复数据的完整性要比RDB强。如果同时不存在，那么Redis就相当于一个内存中间件了，类似于Memcached

1.Redis 持久化策略之 RDB

1.RDB工作机制

(1).Redis 调用系统函数fork()，单独启动一个fork子进程
(2).fork子进程从Redis数据库中将数据读取出来写入到一个临时RDB文件
(3).fork子进程完成对临时RDB文件的写入时，Redis 用新的临时RDB文件替换并删除旧的临时RDB文件

注意：RDB 在持久化操作时，会对阻塞IO操作，以提高持久化性能

2.RDB 优缺点

优点：
(1).恢复机制效率较高
     采用了RDB这种持久化策略，整个Redis数据库会只包含一个文件，可以在指定的时间间隔内对数据进行归档，进行文件备份，一旦系统出现灾难性故障，可以非常容易的进行恢复

(2).性能最大化
     RDB 在持久化操作时，会对阻塞IO操作，以提高持久化性能

(3).RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快

缺点：
(1).数据的完整性较低
     Redis 中可以设置不同的保存点（save point）来控制RDB文件的频率，假设设置了每5分钟保存一次RDB文件，在这种情况下，一旦发生故障宕机，可能会丢失这几分钟的数据。

(2).可能会停止客户端请求
     每次保存RDB的时候，都会fork()出一个子进程，由fork子进程来完成持久化操作，如果数据集较大时，fork()可能会非常耗时，导致整个服务器停止服务几百毫秒，甚至是1秒钟。

3.RDB 快照持久化配置

save ：每隔多少秒执行一次保存操作，如果想要关闭RDB持久化，直接save加双引号即可（save “”）

stop-writes-on-bgsave-error：持久化过程中如果失败，Redis是否停止所有请求，默认yes，停止所有请求

rdbcompression：存储时是否使用压缩存储，默认为yes，使用LZF算法压缩存储

rdbchecksum：使用CRC算法进行数据校验，有点是保证数据的完整性，缺点是降低了Redis的性能，据说会降低10%~12%Redis的性能损耗

dbfilename：持久化文件名称，默认为dump.rdb（只是文件名称，不包含路径）

dir：持久化文件路径，默认为./（当前目录）

4.RDB 常用命令

命令	说明
save	执行save命令时，Redis会阻塞客户端请求，同时进行快照操作
bgsave	bgsave执行时，Redis还会继续接受客户端请求，异步执行快照操作
lastsave	获取最后一次成功执行快照操作的时间
flushall	清除所有数据，在一定条件下会执行快照操作

• save 命令

SAVE 命令执行一个同步保存操作，将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。

一般来说，在生产环境很少执行 SAVE 操作，因为它会阻塞所有客户端，保存数据库的任务通常由 BGSAVE 命令异步地执行。然而，如果负责保存数据的后台子进程不幸出现问题时， SAVE 可以作为保存数据的最后手段来使用。

实例：

127.0.0.1:6379> set name "tom"
OK
127.0.0.1:6379> save
OK

• bgsave 命令

在后台异步(Asynchronously)保存当前数据库的数据到磁盘。

BGSAVE 命令执行之后立即返回 OK ，然后 Redis fork 出一个新子进程，原来的 Redis 进程(父进程)继续处理客户端请求，而子进程则负责将数据保存到磁盘，然后退出。

客户端可以通过 LASTSAVE 命令查看相关信息，判断 BGSAVE 命令是否执行成功

实例：

127.0.0.1:6379> set age 18
OK
127.0.0.1:6379> set address "BeiJing"
OK
127.0.0.1:6379> bgsave
Background saving started

• lastsave 命令

返回最近一次 Redis 成功将数据保存到磁盘上的时间，以 UNIX 时间戳格式表示。

实例：

127.0.0.1:6379> lastsave
(integer) 1507351418

• flushall 命令

清空整个 Redis 服务器的数据(删除所有数据库的所有 key )。

实例：

127.0.0.1:6379> keys *
1) "age"
2) "name"
3) "address"
127.0.0.1:6379> flushall
OK
127.0.0.1:6379> keys *
(empty list or set)

2.Redis 持久化策略之 AOF

---

1.AOF 工作机制

Redis 会将每一个收到的命令都通过write函数追加到文件中，默认文件为appendonly.aof，当Redis重启时，通过重写执行文件中保存的写命令，在内存中重建整个数据库的内容。

2.AOF 优缺点

• 优点：

(1).耐久性好
     使用AOF持久化会让Redis 变得非常耐性（much more durable），Redis 中提供了三种不同的fsync策略，默认为每秒执行一次fsync，在这种配置下，Redis 仍然可以保持良好的性能，即便发生故障停机，最多只会丢失一秒的数据

(2).AOF 重写机制
     AOF 文件是一个只进行追加操作的日志文件（append only log），Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。

(3).AOF 文件易懂，易于分析
     AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。

• 缺点：

(1).AOF 状态下的文件要比RDB大
     对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
(2).AOF的恢复效率要低于RDB
(3).AOF 在过去曾经 bug
     因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样

3.AOF 重写

参考：http://redisbook.readthedocs.io/en/latest/internal/aof.html

AOF 文件通过同步 Redis 服务器所执行的命令， 从而实现了数据库状态的记录， 但是， 这种同步方式会造成一个问题： 随着运行时间的流逝， AOF 文件会变得越来越大。为了解决这个问题Redis提供了AOF重写机制。

AOF重写原理：

(1).Redis 接受客户端的命令，然后写入到aof文件中

(2).当满足重写条件后， Redis 将AOF的重写程序放到子进程中执行

(3).子进程在重写AOF期间，Redis 主进程可以继续处理命令，当接受到新的写命令后，Redis 主进程会将这个写命令的协议内容追加到现有的AOF文件，同时追加到AOF重写缓存中。

(4).当子进程完成 AOF 重写之后， 它会向父进程发送一个完成信号

(5).父进程在接到完成信号之后， 会调用一个信号处理函数。将 AOF 重写缓存中的内容全部写入到新 AOF 文件中，对新的 AOF 文件进行改名，覆盖原有的 AOF 文件

AOF 重写触发条件：

(1).调用 bgrewriteaof 命令手动触发
(2).满足如下条件时自动触发AOF重写
     没有 bgsave 命令在进行。
     没有 bgrewriteaof 在进行。
     当前 AOF 文件大小大于 server.aof_rewrite_min_size （默认值为 1 MB）。
     当前 AOF 文件大小和最后一次 AOF 重写后的大小之间的比率大于等于指定的增长百分比。

4.AOF 日志恢复

如果在追加日志时，恰好遇到磁盘空间满或断电等情况，导致日志写入不完整，也没有关系，Redis 中提供了redis-check-aof工具，可以用来进行日志修复，基本步骤如下：

(1).备份被写坏的AOF文件
(2).运行redis-check-aof –fix filename 命令进行修复
(3).使用diff -u 命令来查看两个文件的差异，定位问题
(4).将修复完成的AOF文件移动到Redis安装目录下
(5).重启Redis ，加载修复后的AOF文件

4.AOF 持久化配置

appendonly：是否开启AOF，默认值为no，表示关闭

appendfilename：追加日志文件名称，默认为appendonly.aof

appendfsync：追加模式，有三个值：always、everysec、no，always表示每一次操作向日志文件中追加一次；everysec每秒追加一次，默认值；no 表示不追加，需要手动触发。从持久化角度将，always是最安全的。从效率上将，no是最快的。而redis默认设置进行了折中，选择了everysec。

no-appendfsync-on-rewrite：AOF 重写时，是否允许追加同步。设置为yes表示rewrite期间对新写操作不fsync，暂时存放在内存中，等rewrite完成后再写入，如果这个时候 Redis 挂掉，就会丢失数据（在linux的操作系统的默认设置下，最多会丢失30s的数据）。默认值为no，不会丢失数据，但是会遇到IO阻塞问题，如果应用无法忍受延迟，可以运行少量数据的丢失，那么就设置为yes

auto-aof-rewrite-percentage：当目前 AOF 文件大小超过上一次重写的aof文件大小的百分之多少进行重写，默认值为100，表示当前 AOF 文件大小是上次日志重写得到AOF文件大小的二倍时，自动启动新的日志重写过程

auto-aof-rewrite-min-size：设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写

aof-load-truncated：Redis 启动加载 AOF 文件时，aof文件可能在尾部是不完整的，如果设置为yes，则成功加载前面正确的数据，如果设置为no，则遇到此类情况时，需手工使用redis-check-aof工具修复