全是干货的技术号: 本文已收录在github,欢迎 star/fork: https://github.com/Wasabi1234/Java-Interview-Tutorial
Redis 对外提供数据访问服务时,使用的是常驻内存的数据。如果仅将数据存在内存,一旦宕机重启,数据全部丢失。
redis所有数据保持在内存中,对数据的更新将异步地保存到磁盘上。持久化主要是做灾难恢复、数据恢复,可归类到高可用。
比如你的Redis宕机,你要做的事情是让Redis变得可用,尽快变得可用!
重启Redis,尽快让它对外提供服务,若你没做数据备份,即使Redis启动了,数据都没了!可用什么呢?
很可能说,大量的请求过来,缓存全部无法命中,在Redis里根本找不到数据,这个时候就造成缓存雪崩,就会去MySQL数据库去找,突然MySQL承接高并发,宕机!
MySQL宕机,你都没法去找数据恢复到Redis里面去,Redis的数据从哪儿来?就是从MySQL来的!
若你把Redis的持久化做好,备份和恢复方案也做到,那么即使你的Redis故障,也可通过备份数据,快速恢复,一旦恢复立即对外提供服务
Redis提供了两种持久化方式:
RDB 按指定时间间隔执行数据集的时间点快照,类似于MySQL Dump。
AOF 会记录服务器接收的每个写操作,这些操作将在服务器启动时再次执行,以重建原始数据集。使用与Redis协议本身相同的格式记录命令,并且仅采用append-only
方式。当日志太大时,Redis可以在后台重写日志。类似于MySQL Binlog、Hbase HLog。在Redis重启时,通过回放日志中的写入指令来重构整个数据。
如果希望Redis仅作为纯内存的缓存来用,亦可禁用RDB和AOF。 可以在同一实例中同时使用AOF和RDB。这种情况下,当Redis重新启动时,AOF文件将用于重建原始数据集,因为它可以保证是最完整的。
最重要的是理解RDB与AOF持久性之间的不同权衡。如果同时使用RDB和AOF两种持久化机制,那么在Redis重启时,会使用AOF来重新构建数据,因为AOF中的数据更加完整!
Redis Server在有多db 中存储的K.V可理解为Redis的一个状态。当发生写操作
时,Redis就会从一个状态切换到另外一个状态。
基于全量的持久化就是在某个时刻,将Redis的所有数据持久化到硬盘中,形成一个快照。当Redis 重启时,通过加载最近一个快照数据,可以将 Redis 恢复至最近一次持久化状态上。
save 可以由客户端显示触发,也可在redis shutdown 时触发。
save本身是单线程串行
方式执行,因此当数据量大时,可能会发生Redis Server的长时间卡顿。但其备份期间不会有其他命令执行,因此备份时期 数据的状态始终是一致性
的。
若存在老的RDB文件,则新的会替换老的,时间复杂度O(N)。
bgsave 也可由
bgsave命令在执行时,会fork
一个子进程。子进程提交完成后,会立即给客户端返回响应,备份操作在后台异步执行,期间不会影响Redis的正常响应。
对于bgsave来说,当父进程Fork完子进程之后,异步任务会将当前的内存状态作为一个版本进行复制
在复制过程中产生的变更,不会反映在这次备份当中。
在Redis的默认配置中,当满足下面任一条件,会自动触发 bgsave 的执行:
配置 | seconds | changes |
---|---|---|
save | 900 | 1 |
save | 300 | 10 |
save | 60 | 10000 |
bgsave相对于save的优势是异步执行
,不影响后续命令执行。但Fork子进程,涉及父进程的内存复制,会增加服务器内存开销。当内存开销高到使用虚拟内存时,bgsave的Fork子进程会阻塞运行
,可能会造成秒级不可用。因此使用bgsave需要保证服务器空闲内存足够。
命令 | save | bgsave |
---|---|---|
IO类型 | 同步 | 异步 |
是否阻塞 | 阻塞 | 非阻塞(在fork时阻塞) |
复杂度 | O(N) | O(N) |
优点 | 不会消耗额外内存 | 不阻塞客户端命令 |
缺点 | 阻塞客户端命令 | 需要fork子进程,内存开销大 |
关闭自动RDB:
dbfilename dump-${port}.rdb
dir /redisDataPath
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
RDB记录的是每个状态的全量数据,AOF记录的则是每条写命令的记录,通过所有写命令的执行,最后恢复出最终的数据状态。
默认配置
。
AOF的回放时机也是在机器启动时
,一旦存在AOF,Redis就会选择增量回放
。
因为增量持久化是持续的写盘,相比于全量持久化,数据更加完整。回放过程就是将AOF中存放的命令,重新执行一遍。完成后再继续接收客户端新命令。
随着Redis 持续的运行,会有大量的增量数据append 到AOF 文件中。为了减小硬盘存储和加快恢复速度,Redis 通过rewrite 机制合并历史AOF 记录。如下所示:
原生 AOF
set hello world
set hello java
set hello hehe
incr counter
incr counter
rpush mylist a
rpush mylist b
rpush mylist c
过期数据
AOF 重写
set hello hehe
set counter 2
rpush mylist a b c
aof_base_size
AOF 上次启动和重写的大小(单位:字节)aof_current_size > auto-aof-rewrite-min-size
aof_current_size - aof_base_size/aof_base_size > auto-aof-rewrite-percentage
修改配置文件
appendonly yes
appendfilename "appendonly-$(port).aof"
appendfsync everysec
dir /opt/soft/redis/data
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
no-appendfsync-on-rewrite yes
append-only
模式追加写
所以没有任何磁盘寻址的开销,写入性能高,且文件不易破损,即使文件尾部破损,也易修复命令 | RDB | AOF |
---|---|---|
启动优先级 | 低 | 高 |
体积 | 低 | 高 |
恢复速度 | 快 | 慢 |
数据安全性 | 丢数据 | 根据策略决定 |
量级 | 重量级 | 轻量级 |
参考
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。