Redis 数据持久化

x33g5p2x  于2021-11-13 转载在 Redis  
字(2.5k)|赞(0)|评价(0)|浏览(254)

1. 背景

持久化保证了redis宕机或是断电等突发情况下可以进行数据恢复,以至于不丢失数据

2. Redis持久化方式

2.1 Rdb方式

Rdb方式是通过手动(save-阻塞式,bgsave-异步)或周期性方式保存redis中key/value的一种机制,Rdb方式一般为redis的默认数据持久化方式.系统启动时会自动开启这种方式的持久化机制。
也可按规则自己配置 redis.conf
redis.conf文件位置👇

使用指令vim redis.conf可编辑修改文件

这里表示每隔60s,如果有超过1000个key发生了变更,那么就生成一个新的dump.rdb文件,就是当前redis内存中完整的数据快照,这个操作也被称之为snapshotting(快照)。
save 60 1000
持久化 rdb文件遇到问题时,主进程是否接受写入,yes 表示停止写入,如果是no 表示redis继续提供服务。
stop-writes-on-bgsave-error yes
在进行快照镜像时,是否进行压缩。yes:压缩,但是需要一些cpu的消耗。no:不压缩,需要更多的磁盘空间。
rdbcompression yes
 一个CRC64的校验就被放在了文件末尾,当存储或者加载rbd文件的时候会有一个10%左右的性能下降,为了达到性能的最大化,你可以关掉这个配置项。
rdbchecksum yes
快照的文件名
dbfilename dump.rdb
存放快照的目录
dir /var/lib/redis

测试1

说明rdb方式默认开启,并且保存了数据

测试2

  1. 先存入数据

  1. 查询redis进程并杀死进程

  1. 查询库内数据是否存在

数据仍然存在√
使用save/bgsave

save与bgsave区别

  • save时同步保存(阻塞式持久化),bgsave是异步保存(异步方式持久化),都可以保存数据
  • Redis Save 命令执行一个同步保存操作,将当前 Redis 实例的所有数据快照(snapshot)以 RDB 文件的形式保存到硬盘。
  • BGSAVE 命令执行之后立即返回 OK ,然后 Redis fork 出一个新子进程,原来的 Redis 进程(父进程)继续处理客户端请求,而子进程则负责将数据保存到磁盘,然后退出。

Rdb持久化方式的优点

  • RDB会生成多个数据文件,每个文件表示某一个时刻中redis的数据,适合做冷备,可以将这种完整的数据文件发送到一些远程云服务(阿里云的ODPS)上,定期备份redis中的数据.
  • RDB对redis对外提供的读写服务,影响非常小,可以让redis保持高性能,因为redis主进程只需要fork一个子进程,让子进程执行磁盘IO操作来进行RDB持久化即可。
  • 相对于AOF持久化机制来说,直接基于RDB数据文件来重启和恢复redis进程,更加快速。

Rdb持久化方式的缺点

  • RDB方式每隔5分钟或更长时间做一次快照,期间redis进程宕机会丢失数据。

2. Aof方式

以记录日志的方式持久化,默认关闭,且性能低
appendonly位置👇

某些配置

# 是否开启AOF,默认关闭
appendonly yes
指定 AOF 文件名
#appendfilename appendonly.aof
Redis支持三种刷写模式:
appendfsync always #每次收到写命令就立即强制写入磁盘,类似MySQL的sync_binlog=1,是最安全的。但该模式下速度也是最慢的,一般不推荐使用。
appendfsync everysec #每秒钟强制写入磁盘一次,在性能和持久化方面做平衡,推荐该方式。
appendfsync no     #完全依赖OS的写入,一般为30秒左右一次,性能最好但是持久化最没有保证,不推荐。
    
#在日志重写时,不进行命令追加操作,而只是将其放在缓冲区里,避免与命令的追加造成DISK IO上的冲突。
#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入,默认为no,建议yes
no-appendfsync-on-rewrite yes
#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍时,自动启动新的日志重写过程。
auto-aof-rewrite-percentage 100
#当前AOF文件启动新的日志重写过程的最小值,避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

Aof方式的优点

  • AOF可以更好的保护数据不丢失,一般AOF会每隔1秒,通过一个后台线程执行一次fsync操作,最多丢失1秒钟的数据.
  • AOF日志文件通常以append-only模式写入,所以没有任何磁盘寻址的开销,写入性能非常高,并且文件不容易破损,即使文件尾部破损,也很容易修复。
  • AOF日志文件过大的时候,出现后台重写操作,也不会影响客户端的读写。因为在rewrite log的时候,会对其中的日志进行压缩,创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候,老的日志文件还是照常写入。当新的merge后的日志文件ready的时候,再交换新老日志文件即可。
  • AOF日志文件的命令通过易读的方式进行记录,这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据,只要这个时候后台rewrite还没有发生,那么就可以立即拷贝AOF文件,将最后一条flushall命令给删了,然后再将该AOF文件放回去,就可以通过恢复机制,自动恢复所有数据.

Aof方式的缺点

  • 对于同一份数据来说,AOF日志文件通常比RDB数据快照文件更大。
  • AOF开启后,支持的写QPS会比RDB支持的写QPS低,因为AOF一般会配置成每秒fsync一次日志文件,当然,每秒一次fsync,性能也还是很高的。
  • AOF这种基于命令日志方式,比基于RDB每次持久化一份完整的数据快照文件的方式,更加脆弱一些,容易有bug。不过AOF为了避免rewrite过程导致的bug,因此每次rewrite并不是基于旧的指令日志进行merge的,而是基于当时内存中的数据进行指令的重新构建,这样健壮性会好很多。

相关文章

微信公众号

最新文章

更多