Redis学习(五):Redis的持久化

简介

由于redis是一个内存数据库,所有的数据都是保存在内存当中的,内存当中的数据极易丢失,所以redis的数据持久化就显得尤为重要,在redis当中,提供了两种数据持久化的方式,分别为RDB以及AOF,且redis默认开启的数据持久化方式为RDB方式。

什么是持久化?
将redis内存的数据存储到硬盘中。用于数据的永久存储,防止数据丢失

方案一:RDB方案

Redis会定期保存数据快照至一个rbd文件中,并在启动时自动加载rdb文件,恢复之前保存的数据。可以在配置文件中配置Redis进行快照保存的时机:
save [seconds] [changes]
意为在[seconds]秒内如果发生了[changes]次数据修改,则进行一次RDB快照保存。
RDB方案配置如下
1、在redis.conf 配置文件中添加一个:“save 5 1”(表示5秒发生1次操作便实行一次数据持久化)
2、进入redis客户端,设置一个值,等待5秒退出
3、ps -ef | grep redis :查看redis进程号,并使用:kill -9 进程号,将redis进程杀死
4、重新启动,并登陆客户端,查看(若数据 在表示持久化成功,若数据不在,表示持久化失败)
修改位置:redis下的redis.conf文件,搜索:“save”,出现以下界面进行修改
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
此方式配置 save,时间、次数、在企业中很难掌握,所以一般在企业中不推荐
手动触发持久化
SAVE或者BGSAVE命令手动触发RDB快照保存。SAVE 和 BGSAVE 两个命令都会调用 rdbSave 函数,但它们调用的方式各有不同:

  • SAVE 在数据持久化时,会阻塞 redis 读写任务,此时客户端无法执行读写
  • BGSAVE 在数据持久化时,不会阻塞 redis 读写任务,此时客户端可以正常执行读写。

RDB方案优点

  • 对性能影响最小。Redis在保存RDB快照时会fork出进程进行,几乎不影响Redis处理客户端请求的效率。
  • 每次快照会生成一个完整的数据快照文件,所以可以辅以其他手段保存多个时间点的快照(例如把每天0点的快照备份至其他存储媒介中),作为非常可靠的灾难恢复手段
  • 使用RDB文件进行数据恢复比AOF要快很多

RDB方案缺点

  • 快照时定期生成的,所以在Redis crash(崩溃)时或多或少会丢失一部分数据
  • 如果数据集非常大且CPU不够强(比如单核CPU),Redis在fork子进程时可能会消耗 相对较长的时间,影响Redis对外提供服务的能力。

方案二:AOF方案

采用AOF持久方式时,Redis会把每一个写请求都记录在一个日志文件里。在Redis重启时读取日志文件,进行还原,将数据还原到内存。

AOF提供了三个 fsync(数据同步) 配置,always/everysec/no,通过配置项[appendfsync]指定:

  • appendfsync no:不进行fsync,将flush(刷新)文件的时机交给OS(操作系统),决定,速度最快
  • appendfsync always:每写入一条日志就进行一次fsync操作,数据安全性最高,但速度最慢
  • appendfsync everysec:这种的做法,每秒记录一次,最多丢失一秒钟的数据。

随着AOF不断地记录写操作日志,因为所有的操作都会记录,所以必定会出现一些无用的日志。大量无用的日志会让AOF文件过大,也会让数据恢复的时间过长。不过Redis提供了AOF rewrite功能,可以重写AOF文件,只保留能够把数据恢复到最新状态的最小写操作集。
AOF rewrite可以通过BGREWRITEAOF命令触发,也可以配置Redis定期自动进行:
auto-aof-rewrite-percentage 100

auto-aof-rewrite-min-size 64mb

上面两行配置的含义是,Redis在每次AOF rewrite时,会记录完成rewrite后的AOF日志大小,当AOF日志大小在该基础上增长了100%后,自动进行AOF rewrite。同时如果增长的大小没有达到64mb,则不会进行rewrite。

AOF优点

  • 最安全,在启用 appendfsync always 时,任何已经写入的数据都不会丢失,使用在启用 appendfsync everysec 也至多只会丢失1秒的数据。
  • AOF文件在发生断电等问题时也不会损坏,即使出现了某条日志只写入了一半的情况,也可以使用 redis-check-aof 工具轻松修复。
  • AOF文件易读,可修改,在进行了某些错误的数据清除操作后,只要AOF文件没有rewrite,就可以把AOF文件备份出来,把错误的命令删除,然后恢复数据。

AOF缺点

  • AOF文件通常比RDB文件更大
  • 性能消耗比RDB更高
  • 数据恢复比RDB慢

AOF方案配置

cd /export/servers/redis-3.2.8

vim redis.conf
appendonly yes
# appendfsync always
appendfsync everysec
# appendfsync no

Redis 数据击穿-数据雪崩

在这里插入图片描述
数据击穿

指的是用户到redis汇总获取数据,但redis中没有数据,用户只能到底层的数据库中查找。

数据雪崩

指的是redis由于硬件或软件的各种原因导致的redis内的数据全部消失。

发布了74 篇原创文章 · 获赞 15 · 访问量 4338

猜你喜欢

转载自blog.csdn.net/wzc8961661/article/details/104891341