redis的持久化方案

概述

由于redis是一个基于内存的数据库，所有的数据都是保存在内存当中的，内存当中的数据极易丢失，所以redis的数据持久化就显得尤为重要，在redis当中，提供了两种数据持久化的方式，分别为RDB以及AOF，且redis默认开启的数据持久化方式为RDB方式，下面来详细聊一下这两种模式。

RDB持久化

• RDB方案介绍
  RDB持久化方案就是会定期给redis数据库保存一个快照至一个rdb文件中，redis启动的时候会根据rdb文件进行数据恢复。至于多久会执行一次快照保存可以通过配置文件redis.conf进行设置，也可以手动执行SAVE或者BGSAVE命令进行快照保存。在每次重启redis服务时，新生成的dump.rdb文件都会覆盖掉之前旧的快照文件。
  配置文件形式：

  # 配置如下save方式，会让redis每60秒检查一次数据变更情况，如果在过去60秒发生了100次或以上变更，则进行快照保存
  save 60 100
  

  手动执行命令形式（SAVE或者BGSAVE）：
  - SAVE和BGSAVE都会调用rdbSave函数，但是调用方式不同
  - SAVE直接调用rdbSave，阻塞redis主进程，直到保存完成为止。所以在保存过程中，redis服务不能处理客户端任何请求。
  - BGSAVE会fork出一个子进程，让这个子进程去调用rdbSave，保存完成后向主进程发送信号。redis服务在保存期间依然能对外提供服务。
• RDB方案优点

1. 对性能影响最小。如前文所述，Redis在保存RDB快照时会fork出子进程进行，几乎不影响Redis处理客户端请求的效率。
2. 每次快照会生成一个完整的数据快照文件，所以可以辅以其他手段保存多个时间点的快照（例如把每天0点的快照备份至其他存储媒介中），作为非常可靠的灾难恢复手段。
3. 使用RDB文件进行数据恢复比使用AOF要快很多

• RDB方案缺点

1. 快照是定期生成的，所以在Redis crash时或多或少会丢失一部分数据。
2. 如果数据集非常大且CPU不够强（比如单核CPU），Redis在fork子进程时可能会消耗相对较长的时间，影响Redis对外提供服务的能力。

• RDB方案配置
  在redis.conf中添加如下配置，只要满足其中一个条件，都会触发快照保存。

  save 900 1
  save 300 10
  save 60 10000
  

AOF持久化

• AOF方案介绍
  采用AOF方案是，redis会把对数据库的每一次操作，都记录在一个日志文件中，但是如下情况的记录将会在日志文件中被删除：

  SET key1 value1
  DEL key1
  

  像上述操作，将不会在日志文件中作记录。在redis服务重启时，redis会把AOF文件中的所有记录都执行一遍，（这个和NameNode启动时会读取fsimage和edits文件类似）确保数据恢复到最新。AOF默认是关闭的，如要开启，则要修改配置文件如下：

  appendonly yes
  

  • AOF提供了三种fsync配置，always/everysec/no，通过配置项[appendfsync]指定：
  • appendfsync no：不进行fsync，将flush文件的时机交给OS决定，速度最快appendfsync always：每写入一条日志就进行一次fsync操作，数据安全性最高，但速度最慢
  • appendfsync everysec：折中的做法，交由后台线程每秒fsync一次

  随着AOF不断地记录写操作日志，因为所有的操作都会记录，所以必定会出现一些无用的日志。大量无用的日志会让AOF文件过大，也会让数据恢复的时间过长。不过Redis提供了AOF rewrite功能，可以重写AOF文件，只保留能够把数据恢复到最新状态的最小写操作集。
  AOF rewrite可以通过BGREWRITEAOF命令触发，也可以配置Redis定期自动进行：
  auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb
  上面两行配置的含义是，Redis在每次AOF rewrite时，会记录完成rewrite后的AOF日志大小，当AOF日志大小在该基础上增长了100%后，自动进行AOF rewrite。同时如果增长的大小没有达到64mb，则不会进行rewrite。

• AOF方案优点
  1、 最安全，在启用appendfsync always时，任何已写入的数据都不会丢失，使用在启用appendfsync everysec也至多只会丢失1秒的数据

  2、 AOF文件在发生断电等问题时也不会损坏，即使出现了某条日志只写入了一半的情况，也可以使用redis-check-aof工具轻松修复。

  3、 AOF文件易读，可修改，在进行了某些错误的数据清除操作后，只要AOF文件没有rewrite，就可以把AOF文件备份出来，把错误的命令删除，然后恢复数据。

• AOF方案缺点
  1、 AOF文件通常比RDB文件更大
  2、 性能消耗比RDB高
  3、 数据恢复速度比RDB慢

• AOF方案配置
  编辑redis.conf文件：

  appendonly yes
  appendfsync everysec
  

结语

在实际的生产环境中，这两种方案一般都会混合使用。