【Redis】持久化操作

生活中,最使人疲惫的往往不是道路的遥远,而是心中的郁闷;最使人痛苦的往往不是生活的不幸,而是希望的破灭;最使人颓废的往往不是前途的坎坷,而是自信的丧失;最使人绝望的往往不是挫折的打击,而是心灵的死亡。所以我们要有自己的梦想,让梦想的星光指引着我们走出落漠,走出惆怅,带着我们走进自己的理想。

导读:本篇文章讲解 【Redis】持久化操作,希望对大家有帮助,欢迎收藏,转发!站点地址:www.bmabk.com,来源:原文

一、RDB(Redis Database)

1、持久化
redis一般是将数据写到内存中,但也可以将数据写到磁盘中,这个过程称之为持久化

2、什么是RDB
指定的时间间隔内将内存中的数据集快照写入磁盘中

3、RDB是如何执行备份操作的
redis会单独创建(fork)一个子进程进行持久化,它先将数据写到一个临时文件中,等到持久化过程结束后,再用这个临时文件去替换上一次持久化好的文件(dump.rdb)

之所以进行这个临时文件覆盖持久化文件的操作,是为了保证数据的一致性、完整性和安全性
如果用直接写入dump.rdb的方式,在同步过程中出现断电等意外情况,就会导致此次持久化出现数据缺失的情况

4、相关配置
我们使用vi查看redis.conf,搜索SNAPSHOTTING查看相关配置

注意save和bgsave的区别:

  • save同步阻塞主进程,只有等save完后成,才能进行新操作
  • bgsave 是fork的子进程,非阻塞,等执行完后会通知主进程,然后关闭子进程
# save命令执行同步保存操作,将当前Redis实例的所有数据快照(snapshort)以RDB文件的方式保存到磁盘
# 可以配置的格式为save m n,m表示秒,n表示数据更改次数
# 也就是说每m秒内进行n次以上数据更改,就会触发持久化操作
save 3600 1

# 当redis无法继续写入磁盘,就关闭redis的写操作
stop-writes-on-bgsave-error yes

# 对存储到磁盘中的快照是否进行压缩存储,如果选择yes,redis会采用LZF算法进行压缩
rdbcompression yes

# The filename where to dump the DB
# RDB持久化生成的文件名
dbfilename dump.rdb

# The working directory.
# dump.rdb保存的地址,这里默认为启动目录下
dir ./

# 临时文件进行替换前,校验数据的完整性
rdbchecksum yes

5、优势

  • 性能最大化,生成RDB 文件的时候,redis 主进程会fork()一个子进程来处理所有保存工作,主进程不需要进行任何磁盘IO 操作
  • RDB 在恢复大数据集时的速度比AOF 的恢复速度要快

6、劣势

  • 使用Fork进程创建临时文件进行数据备份,算上原来的持久化文件,数据需要占用2倍的空间
  • RDB 方式数据没办法做到实时持久化/秒级持久化,因为bgsave 每次运行都要执行fork 操作创建子进程,频繁执行成本过高
  • RDB是定时备份,如果在最后一次备份到下一次备份之间,redis发生故障,那么就会丢失那个时间点后的所有修改

7、RDB数据恢复
根据前面的redis配置文件可以得知
redis启动时,它会去读取启动路径下的RDB的持久化文件dump.rdb,恢复最后一次的快照数据
我们来验证一下

首先我们使用客户端A连接redis服务器,往redis中塞几条数据

127.0.0.1:6379> keys *
(empty array)
127.0.0.1:6379>
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379>
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379>
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
127.0.0.1:6379>

在这里插入图片描述

然后我们使用save或者bgsave命令,进行持久化,也可以修改redis.conf配置让他自动生效
持久化完成之后,我们将dump.rdb复制到某个指定路径下

127.0.0.1:6379> save
OK
127.0.0.1:6379>

在这里插入图片描述

接着清除所有的数据

127.0.0.1:6379> flushall
OK
127.0.0.1:6379>
127.0.0.1:6379> keys *
(empty array)

删除redis启动路径下的dump.rdb,停掉redis进程
然后我们将之前备份的dump.rdb传到redis启动路径下,重启redis服务
在这里插入图片描述

使用keys *可以看到,原来被删除的4个key都恢复了
这就是RDB的数据恢复操作
在这里插入图片描述

二、AOF(Append Only File)

1、什么是AOF
以日志的形式记录写操作(增删改操作),将Redis执行的所有写指令都记录下来到缓冲区(读操作不记录),然后追加到AOF文件中,当redis重新启动时,就会去重新执行一遍日志文件中的命令来恢复数据

2、相关配置
redis的AOF配置是默认关闭的,而且AOF的优先级是高于RDB的
当AOF和RDB同时开启时,启动redis会默认去执行aof文件中的命令

# AOF开启配置,如需打开,需要将此处改为yes
appendonly no

# AOF文件的默认名称
appendfilename "appendonly.aof"

# AOF同步频率,redis 默认配置是 everysec,即每秒刷新一次缓存区
appendfsync always  -----服务器在每次写操作后都将 aof_buf缓冲区中的所有内容写入到AOF文件,然后立即执行fsync()函数同步AOF文件到磁盘,所以always的效率是最慢的,但也是最安全的。可靠性高,性能低
appendfsync everysec  ---服务器在每次写操作后都要 将aof_buf缓冲区中的所有内容写入到AOF文件,并且每隔一秒就要在子线程中对AOF文件进行一次同步,创建一个异步任务执行fsync()函数。可靠性和性能都适中
appendfsync no      -----将缓冲区的内容写入AOF文件后,何时进行同步由操作系统控制,不执行fsync()函数。性能好,可靠性低,宕机可能会丢失较多数据

# no-appendfsync-on-rewrite选项处于打开状态时,在执行BGSAVE命令或者BGREWRITEAOF命令期间,服务器会暂时停止对AOF文件的同步,从而尽可能地减少I/O阻塞
no-appendfsync-on-rewrite no

# 配置了当 aof 文件相较于上一版本的 aof 文件大小的百分比达到多少时触发 AOF 重写,也就是大于上一版本1+100%的大小就重写
auto-aof-rewrite-percentage 100

# 配置了最小能容忍 aof 文件大小,超过这个大小必须进行 AOF 重写
auto-aof-rewrite-min-size 64mb

AOF有重写压缩操作,将几条写操作通过一条复杂的操作实现相同的结果(使用fork出来的子进程进行重写),比如set k1 v1和set k2 v2写为set k1 v1 k2 v2

3、AOF的数据恢复
AOF的恢复和上面RDB的恢复操作是一样,只需要在redis启动前,将需要恢复的数据所存储的AOF文件放在redis的启动路径下即可

4、AOF的异常恢复
如果遇到AOF文件损坏,我们在启动路径下使用redis-check-aof --fix appendonly.aof修复

5、AOF持久化流程

  • 客户端的写操作请求被追加到AOF缓冲区
  • AOF根据持久化策略【always、everysec、no】将操作sync同步到磁盘的AOF文件中
  • AOF文件大小超过重写策略或者手动重写时,会对AOF文件进行rewrite重写,压缩AOF文件容量
  • redis重启时,会去读取AOF的写操作进行数据恢复

6、优势和劣势

  • 优势

    • 丢失数据的概率更低
    • AOF文件比较好理解,可以进行操作分析,删除误操作后,重启redis完成数据的恢复
  • 劣势

    • AOF文件比RDB更占空间
    • 因为要执行记录的写操作,恢复起来更慢

如有错误,欢迎指正!!!

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

文章由极客之音整理,本文链接:https://www.bmabk.com/index.php/post/136732.html

(0)
飞熊的头像飞熊bm

相关推荐

发表回复

登录后才能评论
极客之音——专业性很强的中文编程技术网站,欢迎收藏到浏览器,订阅我们!