3.redis持久化策略

1.持久化概念：

redis支持 将内存中的数据持久化到磁盘中,在下次启动redis时可以将磁盘中的数据加载到内存中

2.持久化通用的两种方式:

• 快照(某一时刻对数据的备份)
  例如：mmysql dump redis RDB
• 记录日志()
  例如：Mysql binlog Hbase Hlog redis AOF

3.redis持久化之 RDB(redis database)

①RDB概念：

这里写图片描述

②触发机制-主要三种方式：
(1) save(同步)
(2)bgsave(异步)
(3)自动(符合配置文件中 save满足条件)

image.png

save与bgsave

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

自动生成RDB

save  
save 900 1
save 300 10
save 60 10000

释义：
60秒改变10000次,会采用bgsave方式生成RDB文件
300秒改变10次,会自动生成RDB文件

③RDB配置相关

# 每多少秒 数据改变几次 
# 满足下面任一条件进行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 ./

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

image.png

(3)shutdown

RDB存在问题:
① 耗时、耗性能

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

时间戳	save、bgsave
T1	执行多个命令
T2	满足RDB自动创建条件
T3	再次执行多个命令
T4	宕机

在T4时刻redis出现宕机,会导致T3-T4时刻的数据丢失
如何解决？ 请看下一节AOF持久化方式吧

4.redis持久化之AOF(Append-only file)

client每次请求redis，都会将写请求的命令保存到文件中，

①AOF三种策略

aof三种策略

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

命令	always	everysec	no
优点	不丢失数据	每秒一次fsync只丢失1秒数据	交由操作系统fsync,不用管
缺点	磁盘开销较大,一般sata磁盘一秒只有几百TPS	丢失1秒数据	交由操作系统fsync,不可控

总结：
是业务情况,场景而定，一般可以使用everysec,在磁盘开销及数据丢失情况取个折中

aof相关配置

#是否启用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

②AOF重写
引入原因：
随着数据的不断写入,会造成AOF文件不断增大,重复的命令会额外占用磁盘空间,而是增加redis重启速度
AOF重写定义：

AOF重写

AOF文件重写不是对原有AOF文件进行读取分析,而是读取最新的数据进行分析实现的。

AOF重写作用：
1.减少磁盘占用量
2.加速启动速度
AOF重写触发机制
1.bgrewriteaof

bgrewriteaof

2.AOF重写配置（同时满足配置文件中auto-aof-rewrite-percentage auto-aof-rewrite-min-size两个配置）
bgwriteaof命令

这里写图片描述

AOF重写流程

这里写图片描述

注：
aof_rewrite是在子进程执行，子进程带有主进程数据副本,不会阻塞客户端请求
子进程在AOF重写期间,主进程依然需要会记录数据变化日志，就会出现当前数据与AOF重写之后的数据不一致
解决方案：
redis增加了一个aof_rewrite_buf(aof重写缓冲区),当主进程fork出子进程后开始启用,此时主进程需要将日志同时记录到aof_buf(aof缓冲区)与aof_ewrite_aof(aof重写缓冲区),当子进程重写完数据后给主进程发送信号,此时 主进程通过信号处理函数将aof_rewrite_buf数据追加到新aof文件后，替换旧aof文件

5.混合持久化

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。 Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。AOF在重写(aof文件里可能有太多没用指令，所以aof会定期根据内存的最新数据生成aof文件)时将重写这一刻之前的内存rdb快照文件的内容和增量的 AOF修改内存数据的命令日志文件存在一起，都写入新的aof文件，新的文件一开始不叫appendonly.aof，等到重写完新的AOF文件才会进行改名，原子的覆盖原有的AOF文件，完成新旧两个AOF文件的替换；
AOF根据配置规则在后台自动重写，也可以人为执行命令bgrewriteaof重写AOF。 于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。
相关配置：

#redis 4.0引入
# 是否开启混合持久化
aof-use-rdb-preamble yes

6.总结

①redis存在AOF与RDB两种持久化方式
如果redis宕机或重启时想要恢复数据,会优先采用哪种方式恢复数据呢？
AOF与RDB同时开启时,会优先使用AOF恢复数据,如果采用RDB恢复数据,可以先将AOF关闭,appendonly no,重启完成后，执行config set appendonly yes动态开启AOF