redis详解之数据备份与恢复

一、数据备份

Redis所有数据都是保存在内存中,Redis数据备份可以定期的通过异步方式保存到磁盘上,该方式称为半持久化模式,如果每一次数据变化都写入aof文件里面,则称为全持久化模式。本章节通过配置文件,触发快照的方式,恢复数据的操作,优缺点来学习 Redis 的重点知识——数据备份与恢复

1、方式一:半持久化RDB模式(Redis DataBase)【redis备份默认方式】

通过快照完成,由用户在redis.conf配置文件中设置两个参数:时间和改动的键的个数。当在指定的时间内被更改的键的个数大于指定的数值时,redis会自动将内存中的所有数据进行快照并存储在硬盘上,完成数据备份。备份文件名称:dump.rdb

save  
# save ""
save 900 1
save 300 10
save 60 10000

注:save <指定时间间隔> <执行指定次数更新操作>,官方出厂配置默认是 900秒内有1个更改,300秒内有10个更改以及60秒内有10000个更改,则将内存中的数据快照写入磁盘。可设置多个条件,但条件之间是“或”的关系,只要满足其中一个条件,就会进行快照。如果想禁用自动快照,只需要将所有的save参数删除即可。

拍桌!下面进入问答环节:

Q:通过快照方式完成备份的过程是怎样的?

A:redis使用fork函数复制一份当前进程(父进程)的副本(子进程),父进程继续接收并处理客户端发来的命令,而子进程开始将内存中的数据写入硬盘中的临时文件,当子进程写入完所有数据后会用该临时文件替换旧的RDB文件,至此一次快照操作完成

Q:子线程快照过程中,父线程更改数据会影响备份吗?

A:不会影响。执行fork的时操作系统会使用写时复制(copy-on-write)策略,即fork函数发生的一刻父子进程共享同一内存数据,当父进程要更改其中某片数据时,操作系统会将该片数据复制一份以保证子进程的数据不受影响,所以新的RDB文件存储的是执行fork一刻的内存数据。

Q:除了redis自动执行快照,还可以手动执行吗?

A:当然可以,发送 SAVE 和 BGSAVE 命令可以让redis执行快照,两个命令的区别在于,前者是由主进程进行快照操作,会阻塞住其他请求,后者会通过fork子进程进行快照操作。

Q:说了这么多,RDB有哪些优缺点?

A:RDB优点: ① 适合大规模的数据恢复。② 如果业务对数据完整性和一致性要求不高,RDB是很好的选择。

缺点:
① 数据的完整性和一致性不高,因为RDB可能在最后一次备份时宕机了。
② 备份时占用内存,因为Redis 在备份时会独立创建一个子进程,将数据写入到一个临时文件(此时内存中的数据是原来的两倍哦),最后再将临时文件替换之前的备份文件。
所以Redis 的持久化和数据的恢复要选择在夜深人静的时候执行是比较合理的。

2、方式二:全持久化AOF模式(Append Only File)

Redis 默认不开启。它的出现是为了弥补RDB的不足(数据的不一致性),所以它采用日志的形式来记录每个写操作,并追加到文件中。在启动时Redis会逐个执行AOF文件中的命令来将硬盘中的数据载入到内存中,载入的速度相较RDB会慢一些,开启AOF持久化后每执行一条会更改Redis中的数据的命令,Redis就会将该命令写入硬盘中的AOF文件。AOF文件的保存位置和RDB文件的位置相同,都是通过dir参数设置的,默认的文件名是appendonly.aof,可以通过appendfilename参数修改该名称。

AOF持久化参数配置:

appendonly  yes                    #开启AOF持久化功能;
appendfilename appendonly.aof          #AOF持久化保存文件名;
appendfsync always                     #每次执行写入都会执行同步,最安全也最慢;
#appendfsync everysec                  #每秒执行一次同步操作;
#appendfsync no                    #不主动进行同步操作,而是完全交由操作系统来做,每30秒一次,最快也最不安全;
auto-aof-rewrite-percentage  100      #当AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写,如果之前没有重写过,则以启动时的AOF文件大小为依据;
auto-aof-rewrite-min-size    64mb      #允许重写的最小AOF文件大小配置写入AOF文件后,要求系统刷新硬盘缓存的机制。

Q:从配置文件哪里可以修改备份方式为AOF?

A:打开 redis.conf 文件,找到 APPEND ONLY MODE 对应内容,开启需要手动把no改为yes

appendonly yes

Q:AOF既然采用日志的形式记录写操作,那会不会越来越多?

A:AOF的工作原理是将写操作追加到文件中,文件的冗余内容会越来越多。所以聪明的 Redis 新增了重写机制。当AOF文件的大小超过所设定的阈值时,Redis就会对AOF文件的内容压缩。

重写的原理:Redis 会fork出一条新进程,读取内存中的数据,并重新写到一个临时文件中。并没有读取旧文件,最后替换旧的aof文件。

触发机制:当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。这里的“一倍”和“64M” 可以通过配置文件修改。

Q:AOF的优缺点是什么?

A:优点:数据的完整性和一致性更高
缺点:因为AOF记录的内容多,文件会越来越大,数据恢复也会越来越慢。

二、数据恢复

1、RDB数据恢复

Redis启动后会读取RDB快照文件,将数据从硬盘载入到内存,根据数据量大小与结构和服务器性能不同,通常将一个记录一千万个字符串类型键、大小为1GB的快照文件载入到内存中需花费20~30秒钟。

2、AOF数据恢复

重新启动Redis后Redis会使用AOF文件来恢复数据,因为AOF方式的持久化可能丢失的数据更少,可以在redis.conf中通过appendonly参数开启Redis AOF全持久化模式。

三、总结

  • Redis 默认开启RDB持久化方式,在指定的时间间隔内,执行指定次数的写操作,则将内存中的数据写入到磁盘中。
  • RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
  • Redis 需要手动开启AOF持久化方式,默认是每秒将写操作日志追加到AOF文件中。
  • AOF 的数据完整性比RDB高,但记录内容多了,会影响数据恢复的效率。
  • Redis 针对 AOF文件大的问题,提供重写的瘦身机制。
  • 若只打算用Redis 做缓存,可以关闭持久化。
  • 若打算使用Redis 的持久化。建议RDB和AOF都开启。其实RDB更适合做数据的备份,留一后手。AOF出问题了,还有RDB。

四、参考

1、Redis数据备份与恢复 - 流年晕开时光 - 博客园

2、Redis 持久化之RDB和AOF - ITDragon龙 - 博客园

你可能感兴趣的:(Java基础,redis,java,redis)