Redis持久化

Redis presistence

docker-redis

步骤

1. copy redis.conf 并修改,创建预设的数据卷

2. pull images&&run container

docker run -d \
-v /storage/predis/conf/redis.conf:/usr/local/etc/redis/redis.conf \
-v /storage/predis/dump:/data \
--name  predis redis \
redis-server /usr/local/etc/redis/redis.conf

配置文件(redis.conf)

command	description
dbfilename	filename where dump the DB
save	设置快照时间,默认关闭
dir	工作路径
stop-writes-on-bgsave-error yes	当快照写入出错时,redis是否接受新的写请求
rdbcompression yes	设置是否压缩存储(LZF算法),会消耗CPU资源
rdbchecksum yes	储存sanpshot后进行CRC64校验,产生约10%性能损耗
rdb-del-sync-files no	是否删除主从复制禁用RDB功能的rdb文件
protected-mode yes	默认启动,限制外部连接
daemonize no	是否开启守护线程,docker部署不需要,docker run -d 本身就是后台启动,否则冲突
appendonly no	是否(AOF)持久化,默认关闭
appenddirname	AOF文件夹名
appendfilename	AOF文件名的前缀,redis 7 修改为MP-AOF
auto-aof-rewrite-percentage	自动重写比例
auto-aof-rewrite-min-size	自动重写文件最大体积

RDB(redis database)

概念

固定频率将某一时刻的数据和状态以文件的形式写入到磁盘,RDB文件(dump.rdb),执行全量快照

操作

自动备份

• 执行flushall /flushdb命令会产生dump.db文件,内容为空

• redis重启时,从配置dumpFile目录读取文件,恢复数据

• 备份文件dump.rdb和生产redis服务器尽量不置于同一台机器

手动备份

• save 主程序阻塞redis进程,直到持久化工作完成,线上禁止使用

• bgsave(default) redis在后台异步进行快照操作,不阻塞快照同时可以响应客户端请求,此触发方式会fork一个子进程复制持久化过程

• lastsave 获取最后一次成功执行快照的时间date -d @时间戳

触发RDB snapshot 条件

• 配置文件的默认快照

• save/bgsave

• flushall /flushdb

• 执行shutdown 并未设置开启AOF持久化

• 主从复制,主节点自动触发

缺点

• 可能在故障(down)时丢失最新数据(快照之间的数据)

• 内存数据的全量同步,数据量较大时影响服务器性能

• 主进程fork后,可能会导致服务请求的瞬间延迟

• dump.rdb可能损坏,修复命令 redis-check-rdb /../dump.rdb

禁用snapshot 修改配置文件 save ""

总结

• 适合大规模数据恢复

• 按照业务定时备份

• 对数据完整性和一致性要求不高

• rdb文件在内存的加载速度比aof更快

AOF(append only file)

工作流程

1. Client 作为命令的来源,会有多个源头以及源源不断的请求命令

2. 命令到达redis server 后,存入aof缓存区,等待达到一定量时写入磁盘

3. Aof缓冲会根据Aof缓冲区同步文件的三种写回策略写入磁盘的aof文件

4. 为Aof内容的增加避免文件膨胀,根据规则进行命令合并(AOF重写),达到压缩效果

写回策略

• Always 同步写回,每个写命令执行完会立刻同步的将日志写回磁盘

• everysec 每秒写回,每个写命令执行完,存入Buffer,每隔一秒将Buffer内容写入Disk

• no OS控制写回,每个写命令执行完,先将日志写入到AOF文件的缓冲区,由OS决定何时将Buffer写回Disk

MP-AOF

mp-aof将原来的单个aof文件拆分为多个aof文件(redis7),三种类型

• BASE : 基础AOF,一般由子进程通过重写产生,此文件数量最大为1

• INCR:增量AOF,一般会在AOFRW开始时创建,文件可能多个(一般W操作影响此文件)

• HISTORY:历史AOF,由BASE和INCR AOF变化而来,每次AOFRW成功完成时,本次AOFRW之前对应的BASE和INCR都会变为HISTORY,此类型会被redis自动删除

为管理aof文件,引入manifest文件,所用aof的相关文件会在appenddirname中

缺点

• 相同数据集一般aof大于rdb,恢复速度aof慢于rdb

• aof运行效率一般低于rdb

• 恢复redis-check-aof --fix ...

重写机制

问题:由于AOF持久化是将Redis不断写命令记录到AOF文件中,随着Redis运行,aof文件体积膨胀,占用服务器内存加剧且恢复时间加长,触发重写,保留恢复数据的最小指令集

触发机制

• 自动触发:满足配置文件(auto-aof-rewrite-precentage,auto-aof-rewrite-min-size)的选项,redis自动记录上次重写的AOF文件大小

  • 达到条件时,重写base aof文件,pid增加,incr文件清零

• 手动触发:client发送bgrewrite指令

总结

• 数据实时保存,记录完整的读写命令,同步性更高

• aof日志文件更加灵活,便于追日志

混合模式

• 设置aof-use-rdb-preamble yes,前提开启aof

• RDB镜像做全量持久化,AOF做增量持久化,先使用rdb进行快照存储,然后使用AOF持久化所有写操作,当重写策略满足或者手动触发重写时,将最新的数据存储为RDB记录,重启服务会从二者中恢复数据

纯缓存模式

同时关闭AOF和RDB ,设置redis.conf save " " appendonly no,保证性能