济源做网站,有哪些小程序免费模板平台,北京网站设计公司招聘信息,tawk.to wordpress文章目录 1.RDB1)基本介绍2)自动触发3)手动触发4)RDB文件5)优点缺点 2.AOF1)基本介绍2)使用方式3)工作流程4)重写机制5)AOF文件6)优点缺点 3.RDB AOF 我们都知道#xff0c;redis 是一个基于内存的数据库。基于内存的好处是访问速度快#xff0c;缺点是“不持久”——当数据… 文章目录 1.RDB1)基本介绍2)自动触发3)手动触发4)RDB文件5)优点缺点 2.AOF1)基本介绍2)使用方式3)工作流程4)重写机制5)AOF文件6)优点缺点 3.RDB AOF 我们都知道redis 是一个基于内存的数据库。基于内存的好处是访问速度快缺点是“不持久”——当数据库重启时内存中原先的数据全都会被清空。然而小孩子才做选择redis 说我全都要当插入一份新的数据时在内存中会存储一份在磁盘中也会存储一份当然具体怎么写 redis 有自己的策略从而保证足够的效率 当要访问数据时直接从内存中获取当 redis 重启时可以根据磁盘中的备份来恢复。虽然会消耗更多的磁盘空间然而磁盘资源在计算机世界里可以说是最廉价的了这样的开销并不会带来多大的成本。 Redis官网中列出了如下四种持久化策略 1.RDB
1)基本介绍 RDB(Redis Database)是 redis 中默认使用的持久化策略它的思想是定期对 redis 进行一次全量备份备份数据是二进制的方式存储的其存储路径由配置文件 redis.conf 指定。
RDB持久化过程分为自动触发和手动触发下面分别介绍
2)自动触发
自动触发有三种情况 在m秒内数据集发生了n次修改则自动触发。m和n的具体数值由配置文件决定在我当前的配置文件下有3中选项 注意m与n是并且的关系只有同时满足才会被触发。例如上面的触发条件翻译为距离上一次备份过去 60s 时至少发生了 10000 次修改则触发 rdb 备份另外两条同理。如果你想禁止自动生成 rdb 快照你可以这样修改配置文件save 从节点进行全量复制操作时主节点自动进行RDB持久化随后将RDB文件内容发送给从结点 执行shutdown命令关闭Redis时执行RDB持久化。所以说正常退出 Redis 服务器前都会对当前的数据进行一次备份
3)手动触发
触发命令
手动出发 RDB 的指令有两个
save阻塞当前 Redis 服务端直到RDB过程完成为止。对于内存比较大的实例可能会造成 Redis 服务端的长时间阻塞影响正常的业务请求因此不推荐使用bgsaveRedis 通过 fork() 指令创建子进程由子进程完成 RDB 的持久化过程。阻塞过程只会发生在 fork 阶段但是得益于写时拷贝机制创建子进程的时间一般很短影响不大因此推荐使用
执行流程 执行 bgsave 命令后Redis 父进程会首先检查是否有正在执行 RDB/AOF 备份的子进程如果有 bgsave 就立刻返回间隔时间这么短再开一个子进程备份的意义不大。 父进程执行 fork 创建子进程。fork过程中父进程可能会被阻塞最近一次的fork操作耗时可以在redis 服务端使用 info 指令查看单位为微秒。 父进程 fork() 完成后就可以继续接受客户端的业务请求而将备份的任务交给子进程完成 子进程会向一个临时的快照文件写入 redis 备份数据当备份完成时会删除历史的 dump.rdb 并将该快照文件重命名为 dump.rdb从而保证了自始至终只有一份 rdb 备份文件 子进程通过信号通知父进程 rdb 备份工作完成
实验验证
打开 /var/lib/redis (具体路径因人而异见配置文件)下的 dump.rdb 文件正如我们所预期的一样文件以二进制的形式存储所以呈现出来的都是人眼不能识别的乱码 使用 stat 指令记录下此时的 innode 编号 执行 bgsave 手动完成 rdb 备份时根据 Inode 编号我们就可以发现文件已经被替换了。 4)RDB文件
保存
RDB文件保存在 dir 配置指定的目录默认/var/lib/redis/下文件名通过 dbfilename配置默认dump.rdb指定。 可以通过执行 config set dir{newDir} 和 config set dbfilename{newFilename} 运行期间动态执行当下次运行时RDB文件会保存到新目录
压缩
Redis默认采用 LZF 算法对生成的 RDB 文件做压缩处理压缩后的文件远远小于内存大小默认开启可以通过参数 config set rdbcompression{yes|no} 动态修改 校验
dump.rdb 里面的数据不要乱改修改后可能看不出什么影响也可能会导致数据错误甚至有可能导致 redis 服务端启动失败。 我们手动向 dump.rdb 文件追加数据然后重启 redis 服务端观察结果。使用 keys * 发现似乎没什么影响 我们再尝试在文件中间修改然后重启 redis 服务端观察结果
现在好了连 redis 客户端也连不上了看看日志文件怎么说日志文件路径同样可以在配置文件中找到对应 logfile 配置项 日志说的很明白了都是 RDB 文件格式不对惹的祸。当 dump.rdb 被恶意修改时其结果是不可预期的。对此我们可以使用 redis 提供的 rdb 文件格式检查工具进行检查 5)优点缺点
优点
RDB是一个紧凑压缩的二进制文件代表Redis在某个时间点上的数据快照非常适用于备份全量复制等场景。非常适合灾难恢复因为它是一个可以传输到远程数据中心的单一紧凑文件RDB 持久化策略可以最大化 Redis 的性能因为父进程从不需要执行磁盘I/O或类似操作一切的 IO 工作都交给了子进程完成与AOF相比RDB允许使用大数据集更快地重新启动。因为 RDB 是以二进制的方式存储数据而 AOF 是以文本的形式记录对 redis 的各种数据操作
缺点
RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行 fork 创建子进程属于重量级操作频繁执行成本过高。 因此如果 Redis 服务端在两次备份中间异常退出了正常退出会自动备份那么退出前的新插入的数据就得不到持久化RDB文件使用特定二进制格式保存Redis版本演进过程中有多个RDB版本兼容性可能有风险
2.AOF
1)基本介绍 前面谈到RDB 最大的缺点是不能实时持久化保存数据在两次快照之间实时数据可能会因为 Redis 异常退出而丢失。而 AOF 则可以较好的处理实时性的问题。 AOF类似于mysql中的binlog它会以独立日志的方式记录 Redis 服务端收到的每一条写入操作重启时再重新执行AOF文件中的各种命令达到恢复数据的目的。 AOF 解决了数据的实时性问题因此已经成为了 Redis 持久化的主流方式。
2)使用方式 Redis 中默认采用的持久化策略为 RDB开启 AOF 功能需要设置配置: appendonly yes ,当RDB 与 AOF 可以同时设置但如果开启 AOF Redis 在启动时就会从 AOF 中加载数据 3)工作流程
具体流程 Redis 客户端输入的所有指令都会被追加到 aof_buf 缓冲区中AOF 缓冲区根据策略定期将数据刷新到磁盘随着 AOF 文件越来越大需要定期对 AOF 文件进行重写以达到数据压缩的目的当 Redis 服务器重启时可以加载 AOF 文件进行数据恢复
缓冲区 AOF过程中为什么需要aof_buf这个缓冲区Redis使用单线程响应命令如果每次写AOF文件都直接同步硬盘性能从内存的读写变成IO读写必然会下降。先写入缓冲区可以有效减少IO次数。同时Redis还可以提供三种缓冲区同步策略让用户根据自己的需求做出合理的平衡
no由OS控制 fsync 频率。效率最高但安全性最差always每一次写入都会立即进行 fsync 刷盘。效率最低安全性最高everysec每秒执行一次 fsync。兼顾安全性和效率最常使用 虽然缓冲中的数据在刷盘前也存在丢失的风险但是相较于 RDBAOF的刷新频率很快所以你最多只会丢失 1s甚至一行命令的数据
4)重写机制
基本认识 随着命令不断写入AOF.aof 文件会越来越大Redis 服务端重启的速度自然越来越慢。为了解决这个问题Redis引入 AOF 重写机制来压缩文件体积。 重写机制就是去除冗余操作合并相同操作的过程虽然听起来很复杂但实现起来却很简单因为对于 aof 文件而言并不需要关心中间的各种过程只关心最后 Redis 数据库的状态因此重写的本质是将 Redis 进程内的数据转化为写命令同步到新的 AOF文件
触发条件
AOF 重写过程有自动触发和手动触发两种方式 自动触发触发时机由配置文件中的参数决定两个同样是 “并且” 的关系 auto-aof-rewrite-min-size表示触发重写时AOF的最小文件大小默认为64MB auto-aof-rewrite-percentage代表当前AOF占用大小相比较上次重写时增加的比例默认为 100%意味着至少要是上次重写体积的两倍才触发 手动触发调用 bgrewriteaof 命令
重写流程 如果当前有进程已经在执行 AOF 重写则返回一个 error。如果有进程正在执行 bgsave 命令则 bgsave 完成后重写才会开始父进程创建子进程由子进程完成重写任务父进程fork之后继续响应其他命令 所有修改操作写入 AOF 缓冲区并根据 appendfsync 策略同步到硬盘保证旧 AOF 文件机制正确同时 fork 之后的数据也要写一份到 aof_rewrite_buf 缓冲区中以保证数据的一致性后面具体解释 子进程根据内存快照将数据以命令的形式合并到新的AOF文件中子进程完成重写工作后 子进程向父进程发送信号通知父进程重写工作完成父进程把 aof_rewrite_buf 内临时保存的命令追加到新 AOF 文件中用新 AOF 文件替换老的 AOF 文件 实验方法同上
重写缓冲区
为什么需要重写缓冲区看下面这个例子
时间父进程子进程t1execute command “set key1 1”t2execute command “set key2 2”t3Create subprocess, execute AOF file rewriteStart AOF file rewritet4execute command “set key1 11”execute the rewrite operationt5execute command “set key2 22”execute the rewrite operationt6……Complete AOF rewrite 我们知道进程具有独立性子进程创建后就和父进程在数据上独立了这就意味着子进程只会记录上图中 t3 时刻 Redis 内存中的数据。因此父进程额外开辟了一块缓冲区用于记录fork 后父进程收到的请求在子进程完成重写后再将这块缓冲区追加到 new AOF 文件的结尾就可以保证数据的一致性。
AOF缓冲区 为什么 fork 后父进程还要向 AOF 缓冲区写入数据呢对于安全问题我们往往要考虑到各种极端的情况。如果子进程还没有完成重写 Redis 服务端就异常退出了抑或是主机掉电了那么新 AOF 文件的内容肯定是不完整的内存中的 aof_rewrite_buf 也已经丢失这就意味着 fork 后插入的数据都丢失了。 因为即使 fork 后父进程仍然要向 aof_buf 写入并按照刷新策略定期刷新到磁盘从而保证数据的安全
5)AOF文件 AOF命令写入的内容直接是文本协议格式。例如set hello world这条命令在AOF文件中会追加如下文本 此处遵守Redis格式协议Redis选择文本协议可能的原因文本协议具备较好的兼容性实现简单具备可读性。 对于 AOF 文件redis 同样提供了格式检查工具 redis-check-aof,这里不再重复演示。
6)优点缺点
优点
AOF 策略相比于 RDB 数据更加可靠。everysec 策略下你最多损失 1s 的数据AOF 的重写机制在保证数据安全的前提下避免了 AOF 文件太臃肿AOF 文件以文本的方式包含了各种 operations具有较好的可读性。你甚至可以轻松的导出 AOF 文件例如你不小心的使用 FLUSHALL 删除所有数据你也可以根据 AOF 文件恢复出 FLUSHALL 之前的所有数据在没有 rewrite 的前提下。
缺点
AOF 文件通常比 RDB 文件体积更大AOF 持久化策略通常比 RDB 策略效率低。一般来说在fsync设置为每秒一次的情况下性能仍然很高而在禁用fsync的情况下即使在高负载下它应该与RDB一样快
3.RDB AOF
Redis引入了“混合持久化”的方式结合了 AOF RDB 的优点 按照 AOF 的方式记录每一个请求 在触发 AOF 重写后就把当前内存的状态按照 RDB 二进制文件的格式写入到新的 aof 文件中对上一个文件重写后的结果 后续再进行操作仍然是以 aof 文本的方式追加到 aof 文件末尾
该功能默认开启对应配置文件中的参数如下
