Redis的持久化

Redis提供了2中不同形式的持久化方式。

1. RDB（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘（snapshot快照），恢复时，将快照文件直接读进内存.

1.1 备份如何执行

Redis会单独fork一份和当前进程完全相同的子进程，来进行持久化，会将数据先写入到一个临时文件，待持久化过程都结束了，再用这个临时文件替换上次持久化后创建的RDB文件.

整个过程中主进程是不进行任何IO操作的，这就确保了极高的性能，如果需要进行大规模数据的恢复，且对于数据的完整性不是非常严格，那么RDB方式会比AOF方式更加高效.

RDB的缺点是最后一次持久化后的数据可能会丢失.

1.2 RDB的保存文件

在redis.conf文件中：

# The filename where to dump the DB
dbfilename dump.rdb

RDB文件的保存路径也可以修改，默认是启动redis-cli时所在的工作目录.

# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

1.3 RDB的保存策略

默认的，有下面3组设置：
①每15分钟内，有1次更新
②每5分钟内，有10次更新
③每分钟内，有10000次更新
满足任意一条都会进行RDB持久化操作.

save 900 1
save 300 10
save 60 10000

1.4 手动快照保存

1. save:
阻塞式保存
2. bgsave
非阻塞式保存

1.5 RDB相关配置

1. stop-writes-on-bgsave-error yes
	如果后台进程保存时报错，不允许再写入数据，可以保证数据的一致性，如果不需要可以手动改为no

2. rdbcompression yes
	保存时，是否对rdb文件进行压缩.

3. rdbchecksum yes
	在存储快照后，还可以让Redis使用CRC64算法来进行数据校验，但是这样做会增加额外大概10%的性能损耗，
	如果希望获得最大的性能，可以将它设置为`no`。

1.6 RDB的备份

1. 首先获取RDB文件存储目录

CONFIG GET dir

• 将*.rdb文件拷贝到备份路径
  由于redis每次备份都会将之前的RDB文件移除，那么如果发生故障，可能RDB文件是空的.

1.7 RDB的恢复

• 关闭Redis
  退出客户端，关闭redis server
• 把备份的RDB文件拷贝一份到当前工作目录
• 在当前工作目录启动Redis，它会自动将RDB文件加载到内存，完成恢复

1.8 RDB的优缺点

优点：

• 节省磁盘空间
• 恢复速度快

缺点：

• 虽然Redis在fork时候采用了写时拷贝技术，但是如果数据量较大时还是比较消耗性能
• RDB按照指定的备份策略进行定期备份，但是如果Redis发生宕机，那么很有可能从最后一次RDB快照到当前时间点的操作内容并未被保存到快照.那么数据就会丢失.

2. AOF（Append Only File）

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（不记录读操作），并且是以追加的方式添加到文件尾部，Redis启动时，会将AOF文件中的所有指令，一次执行，来完成恢复工作.

AOF默认是不开启的，如需开启，那么需要修改配置信息：

开启AOF

appendonly yes

默认的AOF文件名也可以在配置文件中修改

appendfilename "appendonly.aof"

AOF的保存路径和RDB文件一样.

2.1 AOF同步频率设置

• 始终同步，每次Redis的写操作都会立刻记入日志

appendfsync always

• 每秒同步，每秒写入日志，如果宕机，则损失1秒的数据

appendfsync everysec

• 不进行同步

appendfsync no

2.2 Rewrite

AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制。

当AOF文件的大小超过所设定的阈值时，Redis就会启动AOF文件的内容压缩.

Rewrite的实现：

AOF文件持续增长而过大时，会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)，遍历新进程的内存中数据，每条记录有一条的Set语句。

重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点类似。

比如，对k1操作的写命令之前有10000条，但是k1只有一个不是吗，结果只是最近一次修改的值，假设为6379，那么直接将这10000条命令都忽略，使用set k1 6379即可

可以使用命令bgrewriteaof，来手动进行

2.3 重写时机

配置文件中默认如下.

# 默认值如下，但是size有点儿小，一般生产都建议5G左右
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小为base_size，如果Redis的AOF当前大小>= base_size +base_size*100% (默认) 且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

2.4 AOF文件备份

AOF的备份机制和性能虽然RDB不同，但是备份和恢复的操作同RDB一样，都是拷贝文件，需要恢复时再拷贝一份回来.

2.5 AOF文件的故障恢复

AOF的保存路径同RDB的路径一样。

如果遇到AOF文件损坏可以使用下面命令来修复：

redis-check-aof --fix appendonly.aof

2.6 AOF的优缺点

优点：

• 备份机制更稳健，丢失数据概率更低
• 可读的日志文本，通过AOF也可以处理误操作.
  缺点：
• 比RDB更加占用磁盘空间
• 恢复备份速度比RDB慢
• 每次读写都同步的话，有一定的性能压力
• 存在个别Bug，造成不能恢复

2.7 AOF和RDB同时开启如何恢复？

AOF和RDB同时开启时，默认由AOF恢复数据.

2.8 用哪个？

• 官方推荐2个都用
• 如果对数据完整性要求不是特别高，可以单独选RDB
• 不建议单独使用AOF，可能会有BUG
• 如果只是做内存缓存，可以都不用

总之，如果有恢复数据的需求，RDB一定要开，至于AOF嘛，看是否对部分数据丢失也可以接受.