Redis学习之持久化

  • Z时代
  • 2024-01-10
  • 分类：综合

database

简介

持久化是将内存中的瞬时数据，转换为存储在磁盘上的持久数据。redis是一个将数据存储在内存中的数据库，这也是它高效率的原因之一。但是将数据存储在内存，如果遇到突发事件，可能会造成数据的丢失。所以我们需要将数据持久化，等下次redis启动时，再次将数据加载进去即可。

RDB和AOF

redis的持久化可以分为两类，一种是快照模式的RDB，一种是日志模式的AOF。

RDB

命令

save:手动保存一次数据

bgsave:手动启动后台存储，不会立刻执行。

配置

dbfilename dump.rdb:设置数据库持久话文件名称

dir:数据文件存储位置

rdbcompression yes:持久化数据是否启用压缩，默认启用。采用lzf压缩。关闭而已节省cpu时间，但是文件会巨大。

rdbchecksum yes:设置是否对rdb文件进行校验。

stop-writes-on-basave-error yes:后台存储的过程中，如果出现错误现象，是否停止保存操作，默认是开启的。

save second changes:限定时间内，key的变化数量达到指定数量，则进行持久化。second:时间 changes:变化数量

工作原理

save命令会将数据记录到 .rdb的文件当中，当下次redis启动时会自动加载这个文件。

因为redis是单线程的，所以当我们执行一个命令的时候，其他命令只能是阻塞状态。因为磁盘的IO是很慢的，在数据量大的情况下我们使用save指令来持久化数据时，可能会造成大量的其他命令造成阻塞，直到整个RDB完毕才会顺序执行其他命令。所以生产环境不会使用save命令。

解决方案

将RDB的过程放到后台执行，不会和其他命令一同放入“任务队列”中。

bgsave:以后台方式进行保存操作，但是不是立刻执行。

当我们执行bgsave命令时，redis会使用它的fork函数启动一个子进程来进行数据的持久化。bgsave是针对save命令阻塞问题进行的优化，建议关于RDB的操作。都使用bgsave

优缺点

  • 缺点

  • RDB是一个紧凑压缩的二进制文件，存储效率高

  • RDB内存储的是redis某一个时间点的数据快照，非常适合数据备份，全量复制等场景。

  • RDB恢复数据要比AOF快很多。

  • 应用：服务器中每X小时，执行一次bgsave 并且将备份文件拷贝到远程机器，用于灾难恢复。

  • 优点

  • RDB无论是使用执行指令还是使用配置，都无法做到实时持久化，具有可能丢失一部分数据的可能性。

  • bgsave执行每次都要创建一个新子进程，会牺牲一些性能，浪费一些内存。

  • Redis各个版本中的RDB文件格式未统一，可能存在不兼容的情况。

AOF

AOF（append only file）以独立的日志方式记录每次操作影响数据的命令，重启时再重新执行一遍AOF文件中的命令以达到恢复数据的效果。与RDB相比可以描述为”该记录数据为记录数据产生的过程“

AOF解决了持久化的实时性，是主流的方式。

工作过程

在使用AOF时，redis会将影响数据的命令首先记录到一个缓存区域，当到达条件时写入到日志文件当中。

AOF写策略

  • always

    每执行一次影响数据命令，就同步到日志文件当中，数据零误差，性能地下。当你的执行命令很快的时候，需要不停的进行io操作，所以这个不常用。

  • everysec

    每秒将缓存区中的执行同步到日志文件当中，数据准确性高，性能较高。在系统宕机时，最坏会丢失1秒的数据。这个也是默认的配置。

  • no

    系统控制，由操作系统控制每次同步到日志文件的的时间，过程不可控制。

配置

  • 开启AOF

    • appendonly yes|no:开启AOF 功能，默认为不开启。

  • 配置策略

    • appendfsync:上边三种策略

  • 配置自动重写

    • auto-aof-rewrite-min-size:当当前的AOF文件尺寸达到这个值，则进行重写 aof_current_zie>auto-aof-rewrite-min-size

    • auto-aof-rewrite-percentage:当当前的AOF文件尺寸增长的百分比达到这个值，则重写

    	aof_current_size-aof_base_size/aof_base_size>auto-aof-rewrite-percentage

AOF重写

随着命令不断的写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF重写是将Redis内部的数据转化为写命令同步到新AOF文件的过程，简单言就是将若干数据转换为命令存储到AOF文件中。

作用

  • 降低磁盘占用

  • 提高持久化效率，降低写时间。

  • 提高恢复效率

AOF规则

  • 超时的数据不会再同步到AOF文件当中。

  • 忽略无效指令，重写时使用内部数据直接生成。

  • 合并同一条数据修改的命令 例如 lpush list1 1,lpush list1 2,lpush list1 3---->>> lpush list1 1 2 3。为了防止数据量过大，对客户端缓冲造成溢出，对于list,set,hash,zset最大只可以一次写入64个数据。

命令

  • bgrewriteaof:手动重写,后台重写AOF，当我们执行这个命令时，redis会调用fork函数创建子进程进行，将数据转换为命令覆盖AOF文件。

AOF和RDB区别

持久化方式

RDB

AOF

占用存储空间

小（数据级：压缩）

大（指令级：重写）

存储速度

慢，数据量大时

快

恢复速度

快

慢

数据安全性

会丢失数据

依策略

资源消耗

高/重量级

低/轻量级

启用优先级

低

高

AOF和RDB的选择

  • 对数据非常敏感，建议使用AOF方案，因为持久化策略使用everysecond，每秒存储一次。该策略在性能上仍然可以保持很好的效果，最坏的情况也仅仅丢失1秒的数据。

  • 数据呈现阶段有效性，建议使用RDB方案，数据可以良好做到阶段内无丢失（该阶段值运维手工维护的阶段），且恢复速度快，阶段点数据使用RDB。

  • 如果不能承受分钟以内的数据丢失，对业务数据非常敏感，则使用AOF

  • 如果能承受分钟以内的数据丢失，且追求大数据集的快速恢复，选用RDB

  • 灾难恢复选择RDB

  • 双保险策略，同时开启RDB和AOF。重启后，Redis会首先使用AOF恢复数据，降低数据丢失的量。

以上是 Redis学习之持久化 的全部内容， 来源链接： utcz.com/z/533345.html

回到顶部