请选择 进入手机版 | 继续访问电脑版

[Redis] 为什么断电后Redis数据不会丢失

[复制链接]
查看155 | 回复21 | 2021-9-14 00:04:56 | 显示全部楼层 |阅读模式
目次

前言

  1. Redis
复制代码
作为一款内存数据库,被广泛利用 于缓存,分布式锁等场景,那么假如断电或者因其他因素导致
  1. Reids
复制代码
服务宕机,在重启之后数据会丢失吗?

Redis 持久化机制

  1. Redis
复制代码
固然 是定义为一个内存数据库,但是其也支持数据的持久化,在
  1. Redis
复制代码
中提供了两种持久化机制:
  1. RDB
复制代码
持久化和
  1. AOF
复制代码
持久化。

RDB 持久化机制

  1. RDB
复制代码
全称为:
  1. Redis DataBase
复制代码
,是
  1. Redis
复制代码
当中默认的持久化方案。当触发持久化条件时,
  1. Redis
复制代码
默认会天生 一个
  1. dump.rdb
复制代码
文件,
  1. Redis
复制代码
在重启的时间 就会通过分析
  1. dump.rdb
复制代码
文件举行 数据恢复。

RDB 机制触发条件

  1. RDB
复制代码
持久化机制有两种触发方式:自动 触发和手动触发。

自动 触发

自动 触发方式也可以分为三种:

  • 实行
    1. flushall
    复制代码
    下令 (
    1. flushdb
    复制代码
    下令 不会触发)时,不过此时天生 的
    1. dump
    复制代码
    文件内的数据是空的(
    1. dump
    复制代码
    文件还会存储一些头信息,以是 文件本身是有内容的,只是没有数据),没有什么太大的现实 意义。
  • 实行
    1. shutdown
    复制代码
    下令 时会触发天生
    1. dump
    复制代码
    文件。
  • 通过设置 文件自动 天生 ,
    1. Redis
    复制代码
    中设置 文件默认设置 如下,只要达到这三个条件中的恣意 一个,就会触发
    1. Redis
    复制代码
    1. RDB
    复制代码
    持久化机制。
  1. save 900 1 //900秒内至少有1个key被添加或者更新
  2. save 300 10 //300秒内至少有10个key被添加或者更新
  3. save 60 10000 //60秒内至少有10000个key被添加或者更新
复制代码

手动触发

除了自动 触发,

  1. Redis
复制代码
中还提供了
  1. 2
复制代码
个手动触发
  1. RDB
复制代码
机制的下令 (这两个下令 不能同时被实行 ,一旦一个下令 正在实行 中,另一个下令 会被拒绝实行 ):

    1. save
    复制代码
    :这个下令 会壅闭
    1. Redis
    复制代码
    服务器历程 ,直到成功创建
    1. RDB
    复制代码
    文件,也就是说在天生
    1. RDB
    复制代码
    文件之前,服务器不能处理客户端发送的任何下令 。
    1. bgsave
    复制代码
    :父历程 会实行
    1. fork
    复制代码
    操作来创建一个子历程 。
    1. RDB
    复制代码
    文件由子历程 来负责天生 ,父历程 可以正常处理客户端发送的下令 (这里也是
    1. Redis
    复制代码
    不仅仅只是单线程的一个表现 )。

假如 想要知道上一次成功实行

  1. save
复制代码
或者
  1. bgsave
复制代码
下令 的时间,可以实行
  1. lastsave
复制代码
下令 举行 查看,
  1. lastsave
复制代码
下令 返回的是一个
  1. unix
复制代码
时间戳。

RDB 机制干系 设置 文件

除了上面提到的触发天生

  1. rdb
复制代码
文件的设置 参数,
  1. RDB
复制代码
持久化机制还有如下一些干系 下令 :

  1. dir
复制代码
  1. rdb
复制代码
文件天生 目次 。默认是
  1. ./
复制代码
(当前目次 ),可以实行 下令
  1. config get dir
复制代码
举行 查看,如下图所示阐明 当前
  1. dump
复制代码
文件天生 目次 为
  1. /usr/local/redis-5.0.5/bin
复制代码

在这里插入图片形貌

  1. dbfilename
复制代码
  1. rdb
复制代码
文件名。默认是
  1. dump.rdb
复制代码

  1. rdbcompression
复制代码
  1. rdb
复制代码
文件是否是
  1. LZF
复制代码
压缩文件。默认是
  1. yes
复制代码

  1. rdbchecksum
复制代码
:是否开启数据校验。默认是
  1. yes
复制代码

RDB 机制长处

    1. RDB
    复制代码
    是一个非常紧凑的压缩文件,保存了不同时间点上的文件,非常得当 用来灾备和数据恢复。
    1. RDB
    复制代码
    最大限度地进步 了
    1. Redis
    复制代码
    的性能,由于
    1. Redis
    复制代码
    父历程 必要 做的唯一的工作就是派生一个子历程 来完成剩下的工作,父历程 永久 不会实行 磁盘
    1. I/O
    复制代码
    或雷同 的耗时操作。
  • 与后面先容 的
    1. AOF
    复制代码
    持久化机制比较,
    1. RDB
    复制代码
    方式恢复数据的速率 更快。

RDB 机制缺点

    1. RDB
    复制代码
    无法做到及时 备份,以是 假如
    1. Redis
    复制代码
    因非常 制止 工作而没有正确 的关机,那么从上一次备份的到非常 宕机的这一段时间的数据将会丢失。
    1. RDB
    复制代码
    通常必要 父历程 来实行
    1. fork
    复制代码
    操作创建子线程,以是 假如 频仍 实行
    1. fork
    复制代码
    操作而
    1. CPU
    复制代码
    性能又不是很高的话大概 会造成短时间内父历程 不可用。

AOF 持久化机制

  1. AOF
复制代码
全称为:
  1. Append Only File
复制代码
,是
  1. Redis
复制代码
当中提供的另一种持久化机制。
  1. AOF
复制代码
采用日记 的情势 将每个写操作追加到文件中。开启
  1. AOF
复制代码
机制后,只要实行 更改
  1. Redis
复制代码
数据的下令 时,下令 就会被写入到
  1. AOF
复制代码
文件中。在
  1. Redis
复制代码
重启的时间 会根据日记 内容依次实行
  1. AOF
复制代码
文件中的下令 来恢复数据。

  1. AOF
复制代码
  1. RDB
复制代码
最大的不同是:
  1. AOF
复制代码
记录的是实行 下令 (雷同 于
  1. MySQL
复制代码
  1. binlog
复制代码
  1. statement
复制代码
格式),而
  1. RDB
复制代码
记录的是数据(雷同 于
  1. MySQL
复制代码
  1. binlog
复制代码
  1. row
复制代码
格式)。

必要 注意 的是:假犹如 时开启了

  1. RDB
复制代码
  1. AOF
复制代码
两种机制,那么
  1. Redis
复制代码
会优先选择
  1. AOF
复制代码
持久化文件来举行 数据恢复。

AOF 机制怎样 开启

  1. AOF
复制代码
机制默认是关闭的,可以通过以下设置 文件举行 修改

  1. appendonly no //是否开启AOF机制,默认是no表示关闭,修改为yes则表示开启
  2. appendfilename "appendonly.aof" //AOF文件名
复制代码

PS:和

  1. RDB
复制代码
机制一样,其天生 文件的路径也是通过
  1. dir
复制代码
属性举行 设置 。

AOF 机制数据是否及时 写入磁盘

  1. AOF
复制代码
机制下数据是否及时 写入磁盘,这个和
  1. MySQL
复制代码
  1. redo log
复制代码
机制很雷同 ,也是必要 通过参数来举行 控制。

  1. AOF
复制代码
数据何时写入磁盘由参数
  1. appendfsync
复制代码
来举行 控制:

appendfsync 形貌 备注
always 写入缓存的同时关照 操作体系 革新 (fsync)到磁盘(但是也大概 会有部分操作体系 只是尽快刷盘,而不是及时 刷盘) Slow, Safest
everysec 先写入缓存,然后每秒中刷一次盘(默认值),这种模式极端环境 大概 会丢失 1s 的数据 Compromise
no 只写入缓存,什么时间 刷盘由操作体系 本身 决定 Faster

AOF 文件重写

  1. AOF
复制代码
机制重要 是通过记录实行 下令 的方式来实现的,那么随着时间的增长 ,
  1. AOF
复制代码
文件不可避免的会越来越大,而且大概 会出现很多冗余下令 。比犹如 一个
  1. key
复制代码
值实行 了
  1. 10000
复制代码
  1. set
复制代码
操作,现实 上前面
  1. 9999
复制代码
次对恢复数据来说都是没用的,只必要 实行 末了 一次下令 就可以把数据恢复,正是为了避免这种题目 ,
  1. AOF
复制代码
机制就提供了文件重写功能。

重写原理分析

  1. AOF
复制代码
重写时
  1. Redis
复制代码
并不会去分析原有的文件,由于 假如 原有文件过大,分析也会很耗时,以是
  1. Redis
复制代码
选择的做法就是重新去
  1. Redis
复制代码
中读取现有的键值对,然后用一条下令 记录键值对的值

只利用 一条下令 也有一个条件 ,那就是一个集合键或者列表键或者哈希键内包含的元素不能超过

  1. 64
复制代码
个,一旦超过
  1. 64
复制代码
个,就会利用 多条下令 来举行 记录。

AOF 重写缓冲区

  1. AOF
复制代码
重写的时间 一样平常 都会有大量的写操作,以是 为了不壅闭 客户端的下令 哀求 ,
  1. Redis
复制代码
会把重写操作放入到子历程 中实行 ,但是放入子历程 中实行 也会带来一个题目 ,那就是重写期间假如 同时又实行 了客户端发过来的下令 ,又该怎样 保证数据的同等 性?

为了办理 数据不同等 题目 ,

  1. Redis
复制代码
中引入了一个
  1. AOF
复制代码
重写缓冲区。当开始实行
  1. AOF
复制代码
文件重写之后又吸取 到客户端的哀求 下令 ,不但要将下令 写入本来 的
  1. AOF
复制代码
缓冲区(根据上面提到的参数刷盘),还要同时写 入
  1. AOF
复制代码
重写缓冲区:

在这里插入图片形貌

一旦子历程 完成了

  1. AOF
复制代码
文件的重写,此时会向父历程 发出信号,父历程 收到信号之后会举行 壅闭 (壅闭 期间不实行 任何下令 ),并举行 以下两项工作:

    1. AOF
    复制代码
    重写缓冲区的文件革新 到新的
    1. AOF
    复制代码
    文件内。
  1. 将新
    1. AOF
    复制代码
    文件举行 改名并原子的更换 掉旧的
    1. AOF
    复制代码
    文件。

完成了上面的两项工作之后,整个

  1. AOF
复制代码
重写工作完成,父历程 开始正常吸取 下令 。

AOF 机制触发条件

  1. AOF
复制代码
机制的触发条件同样也分为自动 触发和手动触发。

自动 触发:自动 触发可以通过以下参数举行 设置:

  1. auto-aof-rewrite-percentag //文件大小超过上次AOF重写之后的文件的百分比。默认100,也就是默认达到上一次AOF重写文件的2倍之后会再次触发AOF重写
  2. auto-aof-rewrite-min-size //设置允许重写的最小AOF文件大小,默认是64M。主要是避免满足了上面的百分比,但是文件还是很小的情况。
复制代码

手动触发:实行

  1. bgrewriteaof
复制代码
下令 。

注意 :

  1. bgrewriteaof
复制代码
下令 也不能和上面
  1. RDB
复制代码
持久化下令
  1. bgsave
复制代码
同时实行 ,这么做是为了避免同时创建两个子历程 来同时实行 大量写磁盘操作,影响到
  1. Redis
复制代码
的性能。

AOF 机制机制长处

  • 利用
    1. AOF
    复制代码
    机制,可以自由选择不同
    1. fsync
    复制代码
    (刷盘)策略,而且在默认策略下最多也仅仅是丧失
    1. 1s
    复制代码
    的数据。
    1. AOF
    复制代码
    日记 是一个仅追加的日记 ,因此假如 出现断电,也不存在查找或破坏 题目 。即使由于某些缘故原由 (磁盘已满或其他缘故原由 ),日记 已经写了一半的下令 竣事 ,redis-check-aof工具也可以或许 轻松地修复它。
    1. AOF
    复制代码
    文件变得太大时,
    1. Redis
    复制代码
    可以或许 在后台自动 重写。
  • 不同于
    1. RDB
    复制代码
    的文件格式,
    1. AOF
    复制代码
    是一种易于明确 和分析 的格式,依次包含全部 操作的日记 。

AOF 机制机制缺点

  • 对于雷同 的数据集,
    1. AOF
    复制代码
    文件通常比等效的
    1. RDB
    复制代码
    文件大。
  • 根据
    1. fsync
    复制代码
    的具体 策略,
    1. AOF
    复制代码
    机制大概 比
    1. RDB
    复制代码
    机制慢。但是一样平常 环境 下,
    1. fsync
    复制代码
    设置为每秒的性能仍旧 很高,禁用
    1. fsync
    复制代码
    后,即使在高负载下,它的速率 也能和
    1. RDB
    复制代码
    一样快。
  • 由于
    1. AOF
    复制代码
    文件是追加情势 ,大概 会碰到
    1. BRPOP
    复制代码
    1. LPUSH
    复制代码
    等壅闭 下令 的错误,从而导致天生 的
    1. AOF
    复制代码
    在重新加载时不能复制完全雷同 的数据集,而
    1. RDB
    复制代码
    文件每次都是重新从头创建快照,这在肯定 程度上来说
    1. RDB
    复制代码
    文件更加健壮。

总结

本文重要 先容 了

  1. Redis
复制代码
的两种持久化机制:
  1. RDB
复制代码
  1. AOF
复制代码
,并分别先容 了两种持久化机制的原理,通过对两种持久化机制的对比分析了两种持久化机制各自的长处 和缺点。

到此这篇关于为什么断电后Redis数据不会丢失的文章就先容 到这了,更多干系 Redis数据丢失内容请搜刮 脚本之家从前 的文章或继续欣赏 下面的干系 文章渴望 大家以后多多支持脚本之家!


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
回复

使用道具 举报

avatar forregistuse | 2021-9-14 01:31:20 | 显示全部楼层
好帖子!
回复

使用道具 举报

avatar 也空中最亮的兴 | 2021-9-19 10:46:41 | 显示全部楼层
admin楼主是我最崇拜的人!
回复

使用道具 举报

avatar 123457608 | 2021-9-21 09:12:49 | 显示全部楼层
admin楼主,我告诉你一个你不知道的的秘密,有一个牛逼的源码论坛他的站点都是商业源码,还是免费下载的那种!特别好用。访问地址:http://www.mxswl.com 猫先森网络
回复

使用道具 举报

avatar 公务员老虫叭 | 2021-10-4 10:00:51 | 显示全部楼层
小弟默默的路过贵宝地~~~
回复

使用道具 举报

avatar 必须更多木 | 2021-10-5 21:59:38 | 显示全部楼层
这么好的帖子,应该加精华!
回复

使用道具 举报

avatar 马宝清马宝清 | 2021-10-5 21:59:41 | 显示全部楼层
admin楼主的帖子实在是写得太好了。文笔流畅,修辞得体!
回复

使用道具 举报

avatar 眠眠不觉量 | 2021-10-11 13:43:07 | 显示全部楼层
admin楼主主机很热情啊!
回复

使用道具 举报

avatar 茉莉707 | 2021-10-11 13:57:36 | 显示全部楼层
admin楼主是好人!
回复

使用道具 举报

avatar 韶景于璃 | 2021-10-11 13:58:33 | 显示全部楼层
admin楼主加油,看好你哦!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则