- 基于RDB的持久化方式会把当前内存中所有的redis键值对数据以快照的方式写入硬盘文件中,如果需要恢复数据,就把快照文件读到内存中。
- RDB快照文件是经压缩的二进制格式的文件,它的储存路径不仅可以在redis服务器启动前通过配置参数来设置,还可以在redis运行时通过命令来设置。
- 有两种方式可以触发rdb持久化机制
- 通过save和bgsave等命令手动触发
- redis服务器会根据redis.conf配置文件里设置的方式定期把内存数据写入快照
- 基于rdb的持久化方式比较适合备份和灾备场景,但rdb无法实现即时备份,即上次生成快照后的修改会丢失。
save和bgsave命令
- Redis客户端运行save命令后,Redis服务器会把当前内存里的数据写入快照文件,在写入的过程中会暂停执行其他命令,直到写完快照文件。
- 如果当前Redis内存数据很多,那么一旦执行save命令,服务器就会长时间暂停执行命令,造成大量连接阻塞,从而导致线上问题,所以一般在执行save命令时需要非常谨慎。
- 和save命令对应的是bgsave命令,这里bg的含义是background,即后台运行。当用户输入bgsave命令后,Redis服务器会创建一个新的进程,在该进程里把内存数据写入快照文件里,在写的过程中Redis服务器能继续执行其他来自客户端的命令。
- 如果要查看bgsave命令的结果,可以继续执行lastsave命令,该命令返回的是一个时间戳,表示最近一次把内存数据存入快照文件的时间,如果该时间和 bgsave命令的运行时间能对应上,则能说明bgsave命令成功执行。
RDB持久化实践
1.修改配置文件
在redis的redis.conf配置文件中,可以通过save参数配置生成的rdb快照的条件,具体代码如下:
save 600 1
save 300 100
save 60 1000
第一行:表示当在600秒内有一个或者一个以上的键被修改时就会生成快照
第二行:表示当在300秒内有大于或者等于100个键被修改时就会生成快照
第三行:表示当在60秒内有大于或者等于1000个键被修改时就会生成快照
注意:这三个条件是“或”的关系,即只要有一个条件被满足,就会生成快照,从中能看出,rdb持久化文件只是当条件满足后生成快照,所以无法即时保存当前状态的内存数据。也就是说,通过rdb恢复数据时,会丢失上次生成快照后更新的数据
同时,在redis.conf里加上如下两条描述快照文件名的配置:
dbfilename redis.rdb
2.重启redis
检查redis是否启动
ps -ef|grep redis
关闭redis
redis-cli -a 123456 shutdown
重启redis
redis-server redis.conf
3.操作redis
set name pp
查看是否生成redis.rdb文件
两种持久化方式对比
- AOF可以设置一秒写一次持久化文件,所以相对于RDB而言,这种方式能更好地追加内存数据,从而能更好地达到持久化的效果,而且AOF是以“在文件末尾追加”的方式写入数据,所以性能较好
- AOF持久化的文件一般会大于RDB快照,所以用AOF恢复数据时速度会比RDB要慢
- RDB的快照是二进制文件,所以一般比AOF要小,所以在恢复数据时占优势,而且通过bgsave等方式生成快照时,redis服务器会新建一个子进程,所以不会影响redis服务器继续命令执行
- 在实际项目当中可以同时使用这两种方式,当数据误删的情况时,可以用AOF持久化文件来恢复数据,在一般情况下,可以用RDB快照来恢复数据。