深入理解Redis系列之持久化

redis持久化配置

redis.conf

// RDB配置
save 900 1
save 300 10
save 60 10000

// AOF配置
appendonly yes

//AOF三种同步方式
# appendfsync always
appendfsync everysec
# appendfsync no

RDB配置对应saveparams参数：

dirty：距离上一次成功执行SAVE或BGSAVE命令之后，服务器对数据库状态进行了多少次修改

在这里插入图片描述

RDB和AOF对比

在这里插入图片描述

因为AOF更新频率通常比RDB文件高，所以：

  • 如果服务器开启了AOF，那么服务器优先使用AOF文件来还原数据库状态
  • 只有在AOF关闭状态，服务器才使用RDB文件还原数据库状态

在这里插入图片描述

RDB

RDB手动触发和自动触发
  1. 手动触发分别对应save和bgsave命令
  • SAVE：阻塞redis进程，直到RDB文件创建完毕为止
  • BGSAVE：不阻塞，派生出一个子进程，然后由子进程负责创建RDB文件
  • BGSAVE命令执行时，客户端发送SAVE或BGSAVE命令会被拒绝，避免父进程和子进程同时执行两个rdbSave调用，防止产生竞争条件
  • BGSAVE命令执行时，客户端发送BGSAVE命令会被拒绝，避免两个父进程同时执行两个rdbSave调用，防止产生竞争条件
  • BGSAVE命令执行时，客户端发送BGREWRITEAOF命令会被延迟到BGSAVE命令执行完毕之后执行；若是BGREWRITEAOF命令正在执行，客户端发送BGSAVE命令会被拒绝

bgsave执行流程(注意第二步，fork操作创建子进程时，父进程会阻塞)
在这里插入图片描述

  1. redis内部自动触发
  • 使用save相关配置，如save m n，表示m秒内存在n次修改，自动触发bgsave
  • 如果从节点执行全量复制操作，主节点自动执行bgsave生成RDB文件并发送给从节点
  • 执行debug reload命令重新加载redis时，也会触发save操作
  • 默认情况下执行shutdown命令时，如果没有开启AOF持久化功能，则自动执行bgsave

RDB文件载入：在服务器启动时，检测到RDB文件存在，自动载入

RDB文件结构

RDB结构：

  • REDIS： 5字节，保存"REDIS"5个字符
  • db_version：4字节，记录RDB文件的版本号

在这里插入图片描述

database部分：

database 0 代表0数据库所有键值对数据；database 3 代表3数据库所有键值对数据；

在这里插入图片描述

  • SELECTDB：1字节，代表接下来要读一个数据库分区号
    在这里插入图片描述

在这里插入图片描述

AOF

AOF主要作用：解决数据持久化的实时性

AOF工作流程
  1. 所有写入命令会追加到aof_buf（缓冲区）中
  2. AOF缓冲区根据对应的同步策略向硬盘做同步操作
  3. 随着AOF文件越来越大，需要定期对AOF文件进行重写，达到压缩的目的
  4. 当Redis服务器重启时，可以加载AOF文件进行数据恢复

在这里插入图片描述

AOF一些问题
  1. AOF为何直接采用文本协议？
  • 文本协议具有很好的兼容性
  • 开启AOF后，所有写入命令都包含追加操作，直接采用文本协议格式，避免二次处理开销
  • 文本协议具有可读性，方便直接修改和处理
  1. AOF为何把命令追加到aof_buf中？
  • Redis使用单线程响应命令，如果每次写AOF命令都直接写入磁盘，那么性能完全取决当前硬盘负载。另写入缓冲区，可以提供多种缓冲区同步硬盘的策略，在性能和安全性方面做出平衡
文件同步

在这里插入图片描述

重写机制

AOF重写作用：

  • 降低文件占用空间
  • 更小的AOF文件可以更快的被redis加载

重写机制命令或配置：

  1. 手动触发：bgrewriteaof命令
  2. 自动触发配置：
  • auto-aof-rewrite-min-size：AOF重写时，文件最小体积，默认64MB
  • auto-aof-rewrite-percentage：当前AOF空间(aof_current_size)与上一次重写后AOF文件空间(aof_base_size)的比值
  • 自动触发时机：aof_current_size > auto-aof-rewrite-min-size && (aof_current_size - aof_base_size) / aof_base_size >= auto-aof-rewrite-percentage

重写流程：

    1. 执行AOF重写请求
    1. 父进程执行fork创建子进程
    1. 1）父进程fork操作完成后，继续响应其他命令；所有修改命令依然写入AOF缓冲区，并根据appendfsync策略同步到硬盘，保证原有AOF机制正确 2）由于fork操作运用写时复制技术，子进程只能共享fork操作时的内存数据。由于父进程依然响应命令，Redis使用AOF重写缓冲区保存这部分数据，防止AOF文件生成期间丢失这部分数据
  • 子进程根据内存快照，按照命令合并规则写入到新的AOF文件。每次批量写入硬盘数据量由配置aof-rewrite-incremental-fsync控制，默认32MB，防止单次刷盘过多造成硬盘阻塞
  • 新的AOF文件写入完成后，子进程发送信号给父进程，父进程更新统计信息，具体见info persistence下aof_*相关统计
  • 父进程把AOF重写缓冲区的数据写入新的AOF文件
  • 使用新的AOF文件替换老文件，完成AOF重写

在这里插入图片描述

重写AOF文件为什么可以变小：

  • 进程内已经超时的数据不再写入文件
  • 旧的AOF文件含有无效命令，如del key1、hdel key2、srem keys、set a111、set a222等；重写使用进程内数据直接生成，这样新的AOF文件只保留最终数据写入命令
  • 多条写命令可以合并为一个；为防止单条命令过大，造成客户端缓冲区溢出，对于list、set、hash、zset等类型操作，以64个元素为界拆分为多条。
AOF追加阻塞

流程：

  1. 主线程负责写入AOF缓冲区
  2. AOF线程负责每秒执行一次同步磁盘操作，并记录最近一次同步时间
  3. 主线程负责对比上次AOF同步时间：
  • 如果距离上次同步时间小于2s，直接返回
  • 如果距离上次同步时间大于2s，主线程将会阻塞，直到同步操作完成

在这里插入图片描述

可以发现两个问题：

  • everysec配置最多丢失2s数据，不是1s
  • 如果系统fsync缓慢，将会导致redis主线程阻塞，影响效率

每当AOF追加阻塞事件发生时，在info persistence统计中，aof_delayed_fsync指标会累加

一些命令

save //等待RDB文件创建完毕
bgsave //fork生成子进程

config set dir {newDir} //RDB文件保存在dir目录下
config set dbfilename {newFileName} //RDB文件名

config set rdbcompression {yew|no}//默认采用LZF算法进行压缩，默认开启，此命令动态进行修改是否进行压缩

bgrewriteaof //aof文件重写
redis-cli config set appendonly yes //开启aof
redis-cli config set save “” //关闭rdb
info stats
redis-check-aof –fix

参考：
《Redis开发与运维》
《Redis设计与实现》
http://www.redis.cn/documentation.html
https://mp.weixin.qq.com/s/GwjQalQ9ZkBbTBtEKpbkMw
http://www.redis.cn/topics/persistence.html

posted @ 2020-12-31 09:24  曹自标  阅读(187)  评论(0)  编辑  收藏  举报