目录
2.2.2 RDB 文件处理与Redis-check-dump工具的使用
1. Reids 持久化介绍
1.1 RDB持久化简介
RDB 是Redis提供的一种持久化方式, RDB是在特定的时间或者手动将内存中的数据创建快照 (snapshot) 保存到硬盘的过程. 这种持久化的实现方式是, 将数据集以二进制的方式来将数据集保存为RDB文件.
1.2 AOF持久化简介
AOF(append only file) 持久化: 类似mysql 的binlong, 以独立日志的方式, 来存储用户的每次写命令, 重启的时候再执行文件中的命令来达到恢复数据的目的.AOF 主要作用是解决了数据的时效性, 是目前Redis 持久化的主流方式.
2. RDB 持久化详解
2.1 RDB文件的保存与压缩
2.1.1 RDB文件默认名字与路径
RDB 文件默认名字
RDB文件默认路径
2.1.2 压缩算法与配置
RDB文件内存存储的数据
(ps: 内存数据会以二进制的形式压缩存储到rdb文件中, 如果rdb文件被修改或者数据错误, reids 有可能无法启动)
2.2 RDB文件处理
2.2.1 手动备份与自动备份
2.2.1.1 Save命令
save命令会阻塞当前Redis服务器,知道RDB过程完成为止, 对内存比较大的实例会造成长时间阻塞, 影响其他客户端的正常调用, 基本不采用
2.2.1.2 Bgsave命令
redis进程执行 fork操作会创建一个子进程, 由子进程负责进行RDB持久化, 子进程完成后, 会通知父进程持久化完毕, 结束销毁子进程. 阻塞只会发生在fork阶段, 一般时间都很短
2.2.1.3 Bgsave 命令执行流程
- 执行bgsave 命令, 父进程会判断当前是否存在其他子进程, 如存在RDB/AOF子进程, bgsave命令会直接返回
- 父进程执行fork 创建子进程, fork过程会进程阻塞, 通过infostats命令查看 latest_fork_usec选项，可以获取最近⼀次fork操作的耗时，单位为微秒
- ⽗进程fork完成后，bgsave命令返回"Backgroundsavingstarted"信息并不再阻塞⽗进程，可 以继续响应其他命令。
- 子进程创建RDB文件, 根据父进程的内存生成临时文快照件,完成后对原有的文件进行原子替换。(执 ⾏lastsave命令可以获取最后⼀次⽣成RDB的时间，对应info统计的rdb_last_save_time选 项。)
- 进程发送信号给⽗进程表⽰完成，⽗进程更新统计信息。
2.2.2 RDB 文件处理与Redis-check-dump工具的使用
RDB 文件处理
保存: RDB 文件保存在dir 配置指定的目录(默认/var/lib/redis/) 下, 文件名通过配置指定, 来设置下次指定RDB文件保存到新目录.
压缩: 默认采用LZF 算法对⽣成的RDB⽂件做压缩处理，压缩后的⽂件远远⼩于内存⼤ ⼩，默认开启，可以通过参数configsetrdbcompression{yes|no}动态修改。
校验: 启动时加载到损坏的rdb文件会拒绝启动, 这时可以使用redis提供的redis-check-dump 工具检查rdb文件并获取对应的错误报告.
redis-check-dump的使用
正常情况
异常情况(对dump.rdb内容进行修改, 就可以通过检查工具检查出来)
自动备份
自动备份设置的配置文件中, 通过配置文件来进行设置
Save 秒 次数 {秒: 多少后生成快照, 次数: 要满足多少次修改}
以 save 900 1 为例: 当前备份完毕, 15分钟后, 修改次数满足1 次及以上, 就进行备份, 此处的次数和时间的并且的关系
自动配置的时间和次数都可以自定义配置.
RDB的优缺点
• RDB是⼀个紧凑压缩的⼆进制⽂件，代表Redis在某个时间点上的数据快照。⾮常适⽤于备份，全 量复制等场景。⽐如每6⼩时执⾏bgsave备份，并把RDB⽂件复制到远程机器或者⽂件系统中 （如hdfs）⽤于灾备。
• Redis加载RDB恢复数据远远快于AOF的⽅式。
• RDB⽅式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运⾏都要执⾏fork创建⼦进 程，属于重量级操作，频繁执⾏成本过⾼。
• RDB⽂件使⽤特定⼆进制格式保存，Redis版本演进过程中有多个RDB版本，兼容性可能有⻛ 险。
• RDB 是定时备份, 如果服务器掉电或者进行被kill 关闭, 上次备份之后的操作都会因为没来得及备份丢失
3. AOF持久化详解
3.1 AOF持久化开启与配置
AOF 一般默认是关闭状态, 需要通过修改来开启AOF功能
将no改成yes, 开启AOF, 下面的appendonly.aof 就是默认的文件名字
当我们开启AOF 时, RDB 就不生效了, 启动的时候不再读取RDB 文件的内容了.
Redis配置是redis服务器重启后才会生效, 当我们重启redis后, 就可以查看appendonly.aof文件了
Redis 默认路径是 /var/lib/redis, 当我们打开aof 文件后
当我们接下来在redis插入几条数据后
再次打开 appendonly.aof 文件后, 就发现文件里面是有数据了, 可以看出是用过一些特殊字符作为分割符, 来对命令的细节做出区分, 大概的命令还是可以看出
校验数据是否存储成功, 我们强制结束进程, 然后再重启reids查看数据
可以看到,刚才存储的key数据还是存在的
虽然此处redis aof 机制, 也是会读写硬盘, 但实际上, 是相比于mysql, 效率是不太影响的
3.2 AOF 的 工作流程
- 所有的写命令执行后
- AOF 会存储命令 到aof_buf（缓冲区）
- AOF 缓存区根据对应的策略向硬盘进行同步操作
- 随着AOF 的文件越来越大, 需要定期对AOF 文件进行重写,达到压缩的目的.
- 当Redis 服务器重启时, 就可以通加载过AOF 文件进行数据修复
我们可以发现AOF是先将命令存储到缓存区(本质还是在内存中), 然后才写入到AOF文件中, 如果在写入AOF文件前, 服务器突然掉电, 数据是否会丢失呢???
结论是会的
在这块程序员只能进行一定量的取舍, reids也给了程序员一些选择
3.3 AOF 缓冲区的同步文件策略
此处的就类似于mysql的隔离级别
Always: 效率最高, 数据可靠性最高, 性能最低(每次写命令都会将缓冲区的数据同步到磁盘上)
Everysec: 效率低一些,但是性能会提到(reids每隔一秒就会尝试将AOF缓冲区的数据同步到磁盘上, 理论只会丢失1秒的数据)
On: 效率最低, 数据可靠性最低, 性能最高, (Redis 不会主动将缓冲区的数据同步到磁盘上, 而是依赖操作系统定期的操作来同步数据, 这种方式会丢失最近未同步的数据, 但是性能是最好的)
3.4 AOF的文件压缩机制
随着AOF文件持续增大, 体积越来越大, 势必会影响下次redis的启动时间(redis启动的时候需要读取AOF文件的内容, 来恢复数据)
,实际上Redis在重启的时候, 只关注最终的结果, 不需大量的中间数据
如下图
因此redis就存在重写机制, 定期来剔除其中冗余的部分, 合并一些操作, 来达到给AOF文件瘦身的效果
3.5 AOF 重写的触发
手动触发
可以调用 bgrewriteaof 命令
自动触发
根据AOF 重写流程 根据 auto-aof-rerwrit-min-size 和 auto-aof-rewirte-percenntage 产生确定
auto-aof-rerwrit-min-size: 表示触发重写时AOF的最小文件大小, 默认是64MB
auto-aof-rewirte-percenntage: 代表当前AOF占用大小相比较上次重写时增加的比例
配置文件如下
当我们手动执行bgrewriteaof命令后
再次打开appendonly.aof文件后, 可以看到aof存储的数据不是字符了, 就变成了二进制的格式了, 这个机制是结合RDB 提升reids 的启动效率(如果是字符, 那还需要额外的转换)
可以通过配置文件来配置, 开启/关闭该功能(默认开启)
这个选项为是否开启混合持久化
3.6 AOF 的重写流程
我们可以发现AOF 和 RDB的重写流程是有一些相似的
- 执行AOF重写请求
如果当前正在进行AOF重写, 请求不执行. 如果当前执行 bgsave操作, 重写请求将延迟到bgsave执行结束之后执行
- 父进程进行 fork 创建子进程
- 重写开始
- 主进程fork后, 继续响应其他命令, 所有修改操作写入AOF缓冲区并根据appendfsync策略同步到硬盘,保存AOF文件机制正确
- 紫禁城只有fork之前所有的数据, 父进程需要将fork之后的的修改操作写入到AOF重写缓冲区中
- 子进程根据内存快照, 将命令合并到新的AOF文件中
- 子进程完成重写
- 新文件写入后, 子进程发送信号通知父进程
- 父进程把AOF重写缓冲区内临时保存的命令追加到AOF文件中
- 用新AOF文件替换老AOF文件
启动时数据恢复
当Redis启动时，会根据RDB和AOF⽂件的内容，进⾏数据恢复
3.6 AOF恢复数据流程
-
总结
- 5.1 Redis持久化方案比较
- 5.2 RDB与AOF的适用场景
- Redis提供了两种持久化方案 RDB 和 AOF
- RDB视为内存的快照, 产生的内容更加的紧凑,占用的空间比较小, 恢复速度更快, 但产生RDB 的开销比较大, 不是花进行实时持久化, 一般用于冷备份和主从复制
- AOF 视为对修改命令保存, 在恢复时需要重放命令. 并且有重写机制来定期压缩AOF 文件
- RDB 和 AOF 都是使用fork创建子进程的方式, 利用linux 紫禁城拥有父进程快照的特点进行持久化, 尽可能不影响主进程处理后续命令
扫一扫
722
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
