前言
redis在项目中是经常会使用的一种缓存数据库,了解其一些配置和设计思路有利于我们更有效安全的使用它 这次分析一下redis的数据持久化机制,知其然知其所以然。
解析过程
RDB快照处理
在默认情况下,Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中 可以对Redis进行设置,让它在“N秒内数据至少有M个改动”这一条件被满足,自动保存一次数据快照。 在Redis的默认配置如下:
save 900 1
save 300 10
save 60 10000
其意思是Redis满足:900秒内有一个数据被改动,或300秒内有10个数据被改动,或60秒内有10000个数据被改动条件,就会执行RDB持久化保存数据快照。 除了自动满足触发条件进行RDB持久化外,还可以手动命令执行生成RDB快照,在Redis客户端执行save或者bgsave命令会生成dump.rdb文件。 每次命令执行都会将所有redis内存数据快照到一个新的dump.rdb文件,并覆盖原有rdb快照文件。
bgsave-写时复制机制
Redis借助操作系统提供的写时复制机制(copy-on-write,cow),在生成快照的同时,依然可以处理客户端的读写操作命令。简单来说,bgsave子进程是由主进程fork生成的,可以共享主线程的所有内存数据。 bgsave子进程运行后,会开始读取主进程的内存数据并写入RDB文件。此时如果主进程是一些对数据的读操作,那么主进程和子进程互不影响。但如果主进程对数据进行写操作,那么这块被写入的数据被会复制一份,然后子进程把复制的备份写入到RDB文件中,而这个过程中主进程是依旧可以对客户端进行读写操作的。
save和bgsave对比
命令 save bgsave IO类型 同步 异步 是否阻塞redis其他命令 是 否(在主进程生成子进程调用fork函数时会有短暂阻塞) 复杂度 O(N) O(N) 优点 不会消耗额外内存 不会阻塞客户端命令 缺点 阻塞客户端命令 fork子进程,消耗内容
注意:配置自动生成rdb文件redis使用的是bgsave方式。
AOF 持久化机制
使用RDB快照持久化数据,会因为redis宕机或其他故障原因,导致服务器将会丢失掉最近插入且未保存到rdb文件的数据。所以从Redis 1.1版本后,Redis新增一种 AOF持久化机制,将修改的买一条指令都记录到appendonly.aof中(先写入os cache,在隔一段时间fsync到磁盘) 比如执行命令"set iamzrh 24",aof文件记录如下:
*3
$3
set
$6
iamzrh
$2
24
这是一种resp协议格式数据,* 后面数字代表有多少个参数,$后面数字代表参数的字符。 可以通过修改配置文件来打开AOF持久化
appendonly yes
每当Redis执行一个写命令时,例如set,这个命令就会添加到AOP文件末尾。当Redis重启时,程序可以通过执行AOF文件的命令来达到重建数据库的目的。 关于配置Redis多久才将数据fsync到磁盘中,可以通过以下三个命令配置:
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
# appendfsync always
appendfsync everysec
# appendfsync no
always:每次有新的命令追加到AOF文件就执行一次fsync,效率低,但数据安全。 everysec(推荐):每秒fsync一次,效率较高,产生故障只丢失一秒数据,这种策略兼顾速度与安全。 no:从不fsync,将数据交给操作系统处理,更快也更不安全。
AOF 重写
AOF文件可能存在很多没用的指令,所以AOF会定期根据内存的最新数据身材AOF文件。
redis-6379:0>incr iamzrh
(integer) 1
redis-6379:0>incr iamzrh
(integer) 2
redis-6379:0>incr iamzrh
(integer) 3
redis-6379:0>incr iamzrh
(integer) 4
redis-6379:0>incr iamzrh
(integer) 5
redis-6379:0>incr iamzrh
(integer) 6
*3
$3
SET
$6
iamzrh
$1
6
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof文件自上一次重写后文件大小增长了100%会触发重写。 aof文件要达到64M才会重写。 AOF还可以手动执行重写,在Redis客户端执行命令bgrewriteaof重写AOF,注意:aof重写redis会fork一个子进程去做,不会阻塞redis客户端读写命令。
RDB和AOF比较
命令 RDB AOF 启动优先级 低 高 体积 小 大 恢复速度 快 慢 数据安全性 容易丢数据 根据策略决定
Redis 4.0 混合持久化
在Redis重启时,很少使用RDB来恢复内存,因为可能会丢失大量数据。所以通常使用AOF文件恢复数据,但AOF文件恢复shuj相对于RDB来说要很慢,在Redis实例多的情况下,启动可能会话费大量时间。 Redis 4.0为解决这个问题,推出一种新的持久化机制-混合持久化。可以通过如下配置开启混合持久化配置(必须先开启aof):
aof‐use‐rdb‐preamble yes
开启混合持久化后,在AOF重写是,不再单纯将内存数据转化为RESP命令写入AOF文件,而是将重写这一刻之前的内存作为RDB快照,并且将RDB快照和增量的AOF修改内存数据的命令存放在一起,都写入新的AOF文件,新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名,覆盖原有的AOF文件,完成新旧两个AOF文件的替换。 在Redis重启时,可以先加载RDB文件,然后在重放增量的AOF日志就可以完全替代之前的AOF全量数据重放,因此启动效率得到提示。 混合持久化AOF文件格式如下:
Redis数据备份的策略
写crontab定时调度脚本,每小时copy一份rdb或aof的备份到一个目录中去,仅仅保留最近48小时的备份 每天都保留一份当日数据到一个目录中,可以保留最近1个月备份 每次copy备份时,把太旧的数据删除 每天晚上将当前机器的数据备份到另一台机器,防止机器损坏
最后