Redis持久化总结

迷茫凯
82 阅读7分钟

本文内容来自黑马Redis相关课程学习总结

Redis是内存数据库，为防止服务器进程退出导致服务器中的数据库状态消失，Redis提供了持久化功能，可以将Redis在内存中的数据库状态保存到磁盘里面，避免数据意外丢失。

Redis的持久化机制—RDB

1、什么是RDB

全称：Redis DataBase Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。

快照文件称为RDB文件，默认是保存在当前运行目录。

2、RDB文件创建与载入

生成RDB文件命令：SAVE和BGSAVE

SAVE命令：会阻塞Redis服务器进程，服务器不能处理任何命令请求，直到RDB文件创建完毕为止（线上环境不建议使用）；

redis> SAVE
OK

RDB启动方式——save指令相关配置

  • dbfilename dump.rdb

    说明：设置本地数据库名称，默认值为dump.rdb

    经验：通常设置为dump-端口号.rdb

  • dir

    说明：设置存储.rdb文件的路径

    经验：通常设置成存储空间较大的目录中，目录名称data

  • rdbcompression yes

    说明：设置存储至本地数据库时是否压缩数据，默认为yes，采用LZF压缩

    经验：通常默认为开启状态，当设置为no时，可以节省CPU运行时间，但是会使存储的文件变大

  • rdbchecksum yes

    说明：设置是否进行RDB文件格式校验，该校验过程在写文件和读文件过程均进行

    经验：通常默认为开启状态，如果设置为no，可以节约读写过程约10%时间消耗，但是存储有一定的数据损坏风险

BGSAVE命令：派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程（父进程）继续处理命令请求；

redis> BGSAVE
Background saving started

注意：bgsave命令是针对save阻塞问题做的优化。Redis内部所有涉及到RDB操作都采用bgsave的方式，save命令可以放弃使用。

RDB启动方式——bgsave指令相关配置

  • stop-writes-on-bgsave-error yes

    说明：后台存储过程中如果出现错误现象，是否停止保存操作

    经验：通常默认为开启状态

RDB文件的载入工作是在服务器启动时自动执行。

3、自动间隔性保护

Redis允许用户通过设置服务器配置的save选项，让服务器每隔一段时间自动执行一次BGSAVE命令

  • 配置

    save second changes

  • 作用

    满足限定时间范围内key的变化数量达到指定数量即进行持久化

  • 参数

    second：监控时间范围

    changes：监控key的变化量

修改配置文件或者设置启动参数实现：

save 900 1        //900秒内，如果至少有1个key被修改，则执行bgsave
save 300 10        //300秒内，如果至少有10个key被修改，则执行bgsave
save 60 10000    //服务器在60秒之内，如果至少有10000个key被修改，则执行bgsave

只要满足任意一个条件，BGSAVE命令就会被执行。

4、rdb特殊启动形式

  • 全量复制

  • 服务器运行过程中重启

    debug reload

  • 关闭服务器时指定保存数据

    shutdown save

5、RDB总结

RDB方式bgsave的基本流程

  • fork主进程得到一个子进程，共享内存空间
  • 子进程读取内存数据并写入新的RDB文件
  • 用新的RDB文件替换旧的RDB文件

RDB在什么时候执行？save 60 1000代表什么含义

  • 默认是服务停止时
  • 代表60秒内至少执行1000次修改则触发RDB

优点：

  • RDB是一个紧凑压缩的二进制文件，存储效率较高
  • RDB内部存储的是redis在某个时间点的数据快照，非常适合用于数据备份，全量复制等场景
  • RDB恢复数据速度比AOF快很多
  • 应用：服务器每X小时执行bgsave备份，并将RDB文件拷贝到远程机器中，用于灾难恢复

缺点：

  • RDB方式执行时间间隔较长，具有较大的可能性丢失数据
  • bgsave指令每次运行要执行fork操作创建子进程，要牺牲掉一些性能
  • Redis不同版本未进行RDB文件格式统一，可能出现各版本服务之间数据格式无法兼容

Redis的持久化机制—AOF

Append Only File（追加文件）

1、什么是AOF

  • AOF持久化：以独立日志的方式记录每次写命令，重启时再重新执行AOF文件中的命令，达到恢复数据的目的。
  • AOF的主要作用是解决了数据持久化的实时性，目前已经是Redis持久化的主流方式

2、AOF持久化实现

AOF写数据三种策略

  • always（每次）

    每次写入操作均同步到AOF文件中，数据零误差，性能较低

  • everysec（每秒钟）

    写命令执行完成先放入AOF缓冲区，每隔1秒将缓冲区中的指令同步到AOF文件，数据准确性较高，性能较高，是默认方案

    在系统突然宕机的情况下会丢失1秒内的数据

  • no（系统控制）

    写命令执行完成先放入AOF缓冲区，由操作系统控制每次同步到AOF文件的周期，整体过程不可控

AOF功能开启

  • 配置

    appendonly yes|no

  • 作用

    是否开启AOF持久功能，默认为不开启

  • 配置  

    appendfsync always|everysec|no

  • 作用

    AOF写数据策略

  • 配置  

    appendfilename filename

  • 作用

    AOF持久化文件名，默认文件名为appendonly.aof，建议配置为appendonly-端口.aof

  • 配置

    dir

  • 作用

    AOF持久化文件保存路径，与RDB持久化文件保持一致即可

3、AOF重写

随着命令不断写入AOF，文件会越来越大，为了解决这个问题，Redis引入了AOF重写机制压缩文件体积。AOF文件重写是将Redis进程内的数据转化为写命令同步到新AOF文件的过程。简单说就是将对同一个数据的若干条命令执行结果转化成最终结果数据对应的指令进行记录。

AOF重写作用

  • 降低磁盘占用量，提高磁盘利用率
  • 提高持久化效率，降低持久化写时间，提高IO性能
  • 降低数据恢复用时，提高数据恢复效率

AOF重写规则

  • 进程内已超时的数据不再写入文件
  • 忽略无效指令，重写时使用进程内数据直接生成，这样新的AOF文件只保留最终数据的写入命令
  • 对同一数据的多条写命令合并为一条命令

AOF重写方式

  • 手动重写

    bgrewriteaof

  • 自动重写

    auto-aof-rewrite-min-size size
auto-aof-rewrite-percentage percentage

AOF自动重写方式

  • 自动重写触发条件设置

    # AOF文件体积最小多大以上才触发重写
auto-aof-rewrite-min-size size

# AOF文件比上次文件增长超过多少百分比则触发重写
auto-aof-rewrite-percentage percentage

  • 自动重写触发比对参数（运行指令info Persistence获取具体信息）

    aof_current_size
aof_base_size

  • 自动重写触发条件

    aof_current_size > auto-aof-rewrite-min-size
(aof_current_size - aof_base_size)/aof_base_size >= auto-aof-rewrite-percentage

RDB和AOF对比

持久化方式RDBAOF
占用存储空间小（数据级：压缩）大（指令级：重写）
存储速度慢快
宕机恢复速度很快慢
数据安全性会丢失数据依据策略决定
资源消耗高/重量级低/轻量级
数据恢复优先级低，数据完整性不如AOF高

RDB和AOF场景选择

  • 对数据安全性要求较高，建议使用默认的AOF持久化方案
  • 可以容忍数分钟的数据丢失，追求更快的启动速度，建议使用RDB持久化方案
  • 双保险策略，同时开启RDB和AOF

服务器优先使用AOF文件来还原数据库状态，只有在AOF持久化功能处于关闭状态时，服务器才会使用RDB文件来还原数据库状态。

持久化应用场景

  • 用于抢购、限购类、限量发放优惠券、激活码等业务的数据存储设计
  • 用于具有先后顺序的数据控制
  • 用于最新消息展示
  • 用于基于黑名单和白名单设定的服务控制
  • 用于计数器组合排序功能对应的排名
  • 用于按次结算的服务控制
avatar
文章
阅读
粉丝