Redis 持久化

转自ITDragon龙.

Redis 持久化方案

Redis是内存型数据库，为了防止断电或是重启时数据丢失，需要将内存中的数据持久化到硬盘中。
Redis 持久化方案分为两种：RDB （Redis DataBase）和 AOF （Append Only File）。

RDB

RDB 是 Redis 默认的持久化方案。在指定的时间间隔内，执行的写操作达到指定次数时，则会触发快照生成，将内存中的数据写入到磁盘中。即在指定目录下生成一个dump.rdb文件。Redis 重启会通过加载dump.rdb文件恢复数据。

redis.conf 中的RDB

1. RDB 规则配置

################################ SNAPSHOTTING  #################################
#Save the DB on disk:
#save <seconds> <changes>
#save ""
save 900 1
save 300 10
save 60 10000

操作说明：save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘中。默认配置是是 900秒内有1个更改，300秒内有10个更改以及60秒内有10000个更改，则将内存中的数据快照写入磁盘。
若不使用RDB方案，把 save “” 的注释打开，下面三个注释掉就行了。
2. 默认开启了数据压缩功能：rdbcompression yes
3. 默认持久化的数据库文件名为：dump.rdb

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

4. 数据库文件dump.rdb保存目录

# The working directory.
#The DB will be written inside this directory, with the filename specified
#The Append Only File will also be created inside this directory.
dir ./

通过RDB文件恢复数据

将dump.rdb 文件拷贝到redis的安装目录下，重启redis服务即可。

RDB 持久化触发时机

1. 在指定的时间间隔内，执行指定次数的写操作
2. 执行save（阻塞， 只管保存快照，其他的等待） 或者是bgsave （异步）命令
3. 执行flushall 命令，清空数据库所有数据。
4. 执行shutdown 命令，保证服务器正常关闭且不丢失任何数据。

RDB 的优缺点

• 优点：

1. 数据恢复速度快，比较适合大规模的数据恢复。

• 缺点：

1. 数据的完整性和一致性不高，因为RDB可能在最后一次备份时宕机了。
2. 备份时占用内存，Redis 在备份时会独立创建一个子进程，将数据写入到一个内存中另外的临时文件（占用双倍内存空间），最后再将临时文件替换之前的备份文件。因此Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

AOF

Redis 默认不开启。AOF是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

redis.conf 中的AOF

1. 开启AOF

############################## APPEND ONLY MODE ###############################
appendonly yes

2. 日志更新条件设置

# appendfsync always  //同步持久化，每次发生数据变化会立刻写入到磁盘中。性能较差（慢）、数据完整性好（安全）
appendfsync everysec //每秒异步记录一次（默认值）
#appendfsync no //不同步，也就是不记录

3. 数据库名字,默认为appendonly.aof

appendfilename "appendonly.aof"

4. 重写触发条件设置

auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb  //当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。一般都设置为3G，64M太小了。

用appendonly.aof恢复数据

将appendonly.aof 文件拷贝到redis的安装目录下，重启redis服务即可。

AOF优缺点

• 优点：数据完整性和一致性高
• 缺点：当AOF文件很大时，数据恢复速度很慢

AOF重写机制（AOF文件瘦身）

• 由于AOF是将每次写操作的命令都记录下来，有可能会记录很长的冗余命令。比如在数据库中对一个整数0进行了100次INCR 命令，AOF文件中就会有100条INCR命令，恢复数据的时候需要执行100次INCR命令
• 而Redis为了解决AOF中这种冗长的命令，设置了重写机制，即对AOF文件进行瘦身。比如上面的100次INCR命令和一次的SET 100命令的效果是一致的。
• AOF重写机制：Redis 会fork出一条新的子进程（后台执行），首先从数据库中读取键现在的值，然后用一条命令去记录键值对，代替之前记录该键值对的多个命令，并重新写到一个临时文件中，旧的AOF文件已然作废。为了避免执行命令时造成客户端输入缓冲区溢出，重写程序在处理list hash set zset数据类型时，会检查键所包含的元素的个数，如果元素的数量超过了redis.h/REDIS_AOF_REWRITE_ITEMS_PER_CMD常量的值（默认64个），那么重写程序会使用多条命令来记录键的值，而不是单使用一条命令。
• 为了解决数据不一致的问题(AOF重写的时候，内存中又出现了修改情况)，Redis增加了一个AOF重写缓存，这个缓存在fork出子进程之后开始启用，Redis服务器主进程在执行完写命令之后，会同时将这个写命令追加到AOF文件中和AOF重写缓冲区
  即子进程在执行AOF重写时，主进程需要执行以下三个工作：（1）执行client发来的命令请求；（2）将写命令追加到现有的AOF文件中；（3）将写命令追加到AOF重写缓存中。

总结

1. Redis 默认开启RDB持久化方式，在指定的时间间隔内，执行指定次数的写操作，则将内存中的数据写入到磁盘中。
2. RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
3. Redis 需要手动开启AOF持久化方式，默认是每秒将写操作日志追加到AOF文件中。
4. AOF 的数据完整性比RDB高，但记录内容多了，会影响数据恢复的效率。
5. Redis 针对 AOF文件大的问题，提供重写的瘦身机制。
6. 若只打算用Redis 做缓存，可以关闭持久化。
7. 若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份，留一后手。AOF出问题了，还有RDB。