Redis持久化
尚硅谷redis6教程学习笔记,如有不懂可以跳转观看。
1 总体介绍
Redis提供了2个不同形式的持久化方式
- RDB(Redis DataBase)
- AOF(Append Of File)
2 RDB
RDB是在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是Snapshot快照,它恢复时是将快照文件直接读到内存里
2.1 备份是如何执行的
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何的IO操作的,这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
注:如果保持策略是save 30 10,当30秒内发key发生≥10次变化,等30秒结束时会进行持久化,如果30秒key已经发生了≥10次变化,且还没到30秒,但服务器崩了,没有执行持久化,就会导致最后一次数据持久化数据丢失。
2.2 Fork
Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程
在Linux程序中,fork()会产生一个和父进程完全相同的子进程,但子进程在此后多会exec系统调用,出于效率考虑,Linux中引入了“写时复制技术”
一般情况父进程和子进程会共用同一段物理内存,只有进程空间的各段的内容要发生变化时,才会将父进程的内容复制一份给子进程
2.3 RDB持久化流程
2.4 dump.rdb文件
在redis.conf中配置文件名称,默认为dump.rdb
1.先进入redis配置文件
vi /etc/redis/redis.conf
2.再搜索快照位置
/SNAPSHOTTING
或/SN找到SNAPSHOTTING的位置
3.找到dbfilename
2.5 配置位置
rdb文件的保存路径,也可以修改
2.6 如何触发RDB快照;保持策略
2.6.1 配置文件中默认的快照配置
2.6.2 命令save VS bgsave
save:save时只管保存,其他不管,全部阻塞。手动保存。不建议
bgsave:Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。
可以通过lastsave命令获取最后一次成功执行快照的时间
2.6.3 flushall命令
执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义
2.6.4 save
格式 :save 秒钟 写操作次数
RDB是整个内存压缩过的Snapshot,RDB的数据结构,可以配置复合的快照触发条件
默认是1分钟内改了1万次,或者5分钟内改了10次,或15分钟内改了1次
禁用
不设置save指令,或者给save传入空字符串
2.6.5 stop-write-on-bgsave-error
2.6.6 rdbcompression 压缩文件
对于存储到磁盘中的快照,可以设置是否进行压缩存储,如果是的话,redis会采用LZF算法进行压缩。
如果不想消耗CPU来进行压缩的话,可以设置为关闭此功能。推荐yes
2.6.7 rdbchecksum检查完整性
在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能,推荐yes
2.6.8 RDB的备份
- 先通过config get dir 查询RDB文件的目录
- 将.rdb的文件拷贝到别的地方
RDB的恢复
- 关闭Redis
- 先把备份的文件拷贝到工作目录下 cp dum2.rdb dump.rdb
- 启动Redis,备份数据会直接加载
2.7 优势
-
适合大规模的数据恢复
-
对数据完整性和一致性要求不高更适合使用
-
节省磁盘空间
-
恢复速度快
2.8 劣势
- Fork的时候,内存中的数据被克隆了一份,大致2倍的膨胀性需要考虑
- 虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能
- 在备份周期在一定间隔时间做一次备份,所以如果Redis以为down掉的话,就会丢失最后一次快照后的所有修改
2.9 如何停止
动态停止RDB:redis-cli config set save “”
save后给空值,表示禁用保存策略
2.10 RDB总结
3 AOF
AOF是以日志的形式来记录每个写操作(增量保存),将Redis执行过的所有写指令记录下来(读操作不记录)只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
3.1 AOF持久化流程
- 客户端的请求写命令会被append追加到AOF缓冲区内;
- AOF缓冲区根据AOF持久化策略[alwags,everysec,no]将操作sync同步到磁盘的AOF文件中;
- AOF文件大小超过重写策略或手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量;
- Redis服务重启时,会重新load加载AOF文件中的写操作达到数据恢复的目的
3.2 AOF默认不开启
可以再redis.conf中配置文件名称,默认为appendonly.aof
AOF文件的保存路径,同RDB的路径一直
3.3 AOF和RDB同时开启,redis听谁的
AOF和RDB同时开启,系统默认取AOF的数据(数据不会存在丢失)
3.4 AOF启动/修复/恢复
-
AOF的备份机制和性能虽然和RDB不同,但是备份和恢复的操作同RDB一样
-
正常恢复
- 修改默认的appendonly no ,改为yes
- 将有数据的aof文件复制一份保存到对应目录(查看目录:config get dir)
- 恢复:重启redis然后重新加载
-
异常恢复
- 修改默认的appendonly no,改为yes
- 如果遇到AOF文件损坏,通过/usr/local/bin/redis-check-aof–fix appendonly.aof进行恢复
- 备份被写坏的AOF文件
- 恢复:重启redis,然后重新加载
3.5 AOF同步频率设置
-
appendfsync always
始终同步,每次Redis的写入都会立刻记入日志;性能较差但数据完整性比较好
-
appendfsync everysec
每秒同步,每秒记入日志一次,如果宕机,本秒的数据可能丢失。
-
appendfsync no
redis不主动进行同步,把同步时机交给操作系统。
3.6 Rewrite压缩
AOF采用文件追加方式,文件会越来越大,为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会自动AOF文件的内容压缩,只保留可以恢复数据的最小指令集,可以使用命令bgrewriteaof
3.7 优势
- 备份机制更稳健,丢失数据概率更低。
- 可读的日志文本,通过操作AOF稳健,可以处理误操作。
3.8 劣势
- 比起RDB占用更多的磁盘空间
- 恢复备份速度要慢
- 每次读写都同步的话,有一定的性能压力。
- 存在个别Bug
3.9 AOF总结
4 总结
官方推荐两个都启用。
如果对数据不敏感,可以选单独用RDB。
不建议单独用 AOF,因为可能会出现Bug。
如果只是做纯内存缓存,可以都不用。
误操作。