深入理解Redis系列之持久化

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了深入理解Redis系列之持久化，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含4695字，纯文字阅读大概需要7分钟。

内容图文

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操作创建子进程时，父进程会阻塞)

2. 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后，所有写入命令都包含追加操作，直接采用文本协议格式，避免二次处理开销
• 文本协议具有可读性，方便直接修改和处理

2. 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重写请求
• 2. 父进程执行fork创建子进程
• 3. 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

内容总结

以上是互联网集市为您收集整理的深入理解Redis系列之持久化全部内容，希望文章能够帮你解决深入理解Redis系列之持久化所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端