Redis-持久化策略

为什么要使用redis持久化

Redis 是一个内存数据库，所有的数据都直接保存在内存中，那么，一旦 Redis 进程异常退出，或服务器本身异常宕机，我们存储在 Redis 中的数据就凭空消失，再也找不到了。

Redis 作为一个优秀的数据中间件，必定是拥有自己的持久化数据备份机制的，redis 中主要有两种持久化策略，用于将存储在内存中的数据备份到磁盘上，并且在服务器重启时进行备份文件重载。

怎么做持久化

Redis RDB - 快照

RDB 按指定时间间隔执行数据集的时间点快照，类似于MySQL Dump。

Redis AOF - 命令日志

AOF 会记录服务器接收的每个写操作，这些操作将在服务器启动时再次执行，以重建原始数据集。使用与Redis协议本身相同的格式记录命令，并且仅采用append-only方式。当日志太大时，Redis可以在后台重写日志。类似于MySQL Binlog、Hbase HLog。在Redis重启时，通过回放日志中的写入指令来重构整个数据。

对比

一、RDB（Redis DataBase）

• 原理

生成dump.rdb文件

• 触发机制

(1) save(同步)
(2)bgsave(异步)
(3)自动(符合配置文件中 save满足条件)

• save与bgsave

命令	save	bgsave
IO类型	同步	异步
阻塞	是	否(阻塞仅仅会发生在fork出子进程)
复杂度	O(n)	O(n)
优点	不消耗额外内存	不阻塞客户端命令

• 自动

save <seconds> <changes>
save 900 1
save 300 10
save 60 10000
//以上表示seconds做了changes操作时，生成一次快照文件

• 相关配置

# 每多少秒 数据改变几次 
# 满足下面任一条件进行RDB文件生成
#如果线上环境数据量很大时，可以关闭RDB持久化方式 只需要注释下面三个save即可
save 900 1
save 300 10
save 60 10000
#bgsave生成RDB文件出错时是否停止
stop-writes-on-bgsave-error yes
#RDB文件是否采用压缩
rdbcompression yes
#是否对rdb文件校验和校验
#redis 5之后采用CRC64校验方式
rdbchecksum yes
# rdb文件名字
#  目录位置 采用 dir设置
dbfilename dump-6379.rdb
#指定目录路径非文件名
# rdb文件aof文件均采用此目录
dir ./

• 其他触发情况

(1)全量复制
从节点执行全量复制操作的时候，主节点会自动触发bgsave命令生存rdb文件并发送给从节点
(2)debug reload
Redis中的debug reload提供debug级别的重启，不清空内存的一种重启，这种方式也会触发RDB文件的生成。

(3)shutdown

• 缺点

　　① 耗时、耗性能

　　复杂度为o(n)，save时内存数据dump到磁盘：耗时
　　bgsave时，fork()阶段采用copy-on-write策略，会比较耗内存
　　dump到文件造成io开销

　　②不可控，丢失数据

• 优点

1. 存储的文件是紧凑的
2. 适合用于备份，方便恢复不同版本的数据
3. 适合于容灾恢复，备份文件可以在其他服务器恢复
4. 最大化了Redis的性能，备份的时候启动的是子线程，父进程不需要执行IO操作
5. 数据保存比AOF要快

二、AOF（Append Only File）

• 三种策略

① always
只要缓冲区有数据 立马写入文件中
②everysec
每隔一秒将数据从缓冲区写入文件中
③no
写文件的操作交由操作系统控制

• 相关配置

#是否启用AOF持久化方式
appendonly no
#AOF文件名
#目录受Dir控制
appendfilename "appendonly-6379.aof"
#AOF持久化策略
#默认值 everysec
# 有三种 no everysec always
#no        写文件的操作交由操作系统控制
#always    只要缓冲区有数据 立马写入文件中
#everysec  每隔一秒将数据从缓冲区写入文件中
appendfsync everysec
#aof重写期间主进程是否继续讲日志从缓冲区刷新到旧日志文件(上图aof_buf-<旧aof文件)
no-appendfsync-on-rewrite no

#以下两个配置同时满足即可触发AOF重写
#文件增长率
auto-aof-rewrite-percentage 100
#aof重写需要的文件
auto-aof-rewrite-min-size 64mb

• 优点

1. 使用AOF模式更加的灵活，因为可以有不同的fsync策略
2. AOF是一个日志追加文件，所有不需要定位，就算断电也没有损坏问题，哪怕文件末尾是一个写到一半的命令，redus-check-aof工具也可以很轻易的修复
3. 当AOF文件很大的，Redis会自动在后台进行重写。重写是决对安全的，因为Redis是继续往旧的文件里面追加，使用创建当前数据集所需的最小操作集合来创建一个全新的文件，一旦创建完成，Redis就会切换到新文件，开始往新文件进行追加操作
4. AOF包含一个又一个的操作命令，易于理解和解析

• 缺点

1. 对于同样的数据集，AOF文件通常要大于RDB文件
2. AOF可能比RDB要慢，这取决于fsync策略。通常fsync设置为每秒一次的话性能仍然很高，如果关闭sfync，即使在很高的负载下也和RDB一样快。不过，即使在很大的写负载情况下，RDB还是能提供很好的最大延迟保证
3. AOF1通过递增的方式更新数据，而RDB快照是从头开始创建，RDB会更健壮和稳定（所以适用于备份）

三、使用

不要仅使用RDB，因为那样会导致你丢失很多数据

不要仅使用AOF，因为那样有两个问题，你通过AOF做冷备，没有RDB做冷备恢复速度更快；RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug

综合使用AOF和RDB用AOF保证数据不丢失，作为数据恢复的第一选择用RDB做不同程度的冷备，在AOF文件都丢失或损坏不可用时，还可使用RDB快速实现数据恢复