比如做百度知道 .html，这些都是我们不可控制的网站！,企业建网站平台,婚恋网站排名前十名,产品质量推广营销语#x1f4eb;作者简介#xff1a;小明java问道之路#xff0c;2022年度博客之星全国TOP3#xff0c;专注于后端、中间件、计算机底层、架构设计演进与稳定性建工设优化。文章内容兼具广度深度、大厂技术方案#xff0c;对待技术喜欢推理加验证#xff0c;就职于知名金融公… 作者简介小明java问道之路2022年度博客之星全国TOP3专注于后端、中间件、计算机底层、架构设计演进与稳定性建工设优化。文章内容兼具广度深度、大厂技术方案对待技术喜欢推理加验证就职于知名金融公司后端高级工程师。 热衷分享喜欢原创~ 关注我会给你带来一些不一样的认知和成长。 2022博客之星TOP3 | CSDN博客专家 | 后端领域优质创作者 | CSDN内容合伙人 InfoQ(极客邦)签约作者、阿里云专家 | 签约博主、51CTO专家 | TOP红人、华为云享专家 如果此文还不错的话还请关注、点赞、收藏三连支持一下博主~ 文末获取联系 精彩专栏推荐订阅收藏 专栏系列点击解锁 学习路线点击解锁 知识定位 Redis从入门到精通与实战 Redis从入门到精通与实战 围绕原理源码讲解Redis面试知识点与实战 MySQL从入门到精通 MySQL从入门到精通 全面讲解MySQL知识与企业级MySQL实战 计算机底层原理 深入理解计算机系统CSAPP 以深入理解计算机系统为基石构件计算机体系和计算机思维 Linux内核源码解析 围绕Linux内核讲解计算机底层原理与并发 数据结构与企业题库精讲 数据结构与企业题库精讲 结合工作经验深入浅出适合各层次笔试面试算法题精讲 互联网架构分析与实战 企业系统架构分析实践与落地 行业最前沿视角专注于技术架构升级路线、架构实践 互联网企业防资损实践 互联网金融公司的防资损方法论、代码与实践 Java全栈白宝书 精通Java8与函数式编程 本专栏以实战为基础逐步深入Java8以及未来的编程模式 深入理解JVM 详细介绍内存区域、字节码、方法底层类加载和GC等知识 深入理解高并发编程 深入Liunx内核、汇编、C全方位理解并发编程 Spring源码分析 Spring核心七IOC/AOP等源码分析 MyBatis源码分析 MyBatis核心源码分析 Java核心技术 只讲Java核心技术 本文目录
本文目录
本文导读
一、什么是Redis AOF
二、如何开启AOF持久化
三、AOF的原理
1、AOF持久化实现
2、AOF数据恢复
3、AOF三种写回硬盘策略
4、AOF重写机制
5、为什么Redis AOF要先执行命令后写日志
四、AOF和RDB对比
五、Redis4.0的混合持久化模式
总结 本文导读
本文为Redis持久化系列第二篇上一篇【Redis】Redis持久化之RDB详解本文讲解兼具广度与深度首先讲解什么是RedisAOF、如何开启AOF持久化深入其AOF的原理AOF持久化实现、AOF数据恢复、AOF三种写回硬盘策略、AOF重写机制解析RedisAOF要先执行命令后写日志以及在实战过程中AOF和RDB对比最后扩展Redis4.0新特性的混合持久化模式。
一、什么是Redis AOF
Redis提供了两种持久性机制一种是RDB也称为快照模式一种是AOF日志也称为追加模式。
AOF是一个日志文件Redis的每个命令都将以AOF格式写入AOF文件AOF日志仅记录修改内存的指令AOF日志记录不同于MySQL先写入日志然后再执行操作两阶段提交AOF是执行成功的命令然后记录命令在日志文件中当需要恢复时直接导入AOF文件以执行其中的记录并且记录是实时的AOF日志存储Redis服务器的顺序指令序列。
二、如何开启AOF持久化
AOF 机制默认处于未开启状态通过在配置文件中将appendonly参数配置为yes来启用AOF持久性。
#修改配置文件
vim /etc/redis/redis.conf
appendonly yes # 把 no 改为 yes#确定存储文件名是否正确
appendfilename appendonly.aof#重启服务
sudo /etc/init.d/redis-server restart
三、AOF的原理
每当修改Redis的命令时服务器都会将该命令写入appendonly.aof 文件该文件存储服务器执行的所有修改成功的命令。因此只要服务器执行aof文件可以达到恢复数据的目的这个过程也称为命令重演。
1、AOF持久化实现 AOF持久性的实现可以分为命令追加( append 当AOF持久性功能打开时Redis将在执行写入命令后以协议格式即RESPRedis客户端和服务器之间的通信协议将执行的写入命令附加到Redis服务器维护的AOF缓冲区的末尾。)、文件写入( writeRedis将调用flushAppendOnlyFile函数以确定是否需要在每个事件周期结束之前将AOF缓存中的内容写入并同步到AOF文件)、文件同步( sync )、文件重写(rewrite)和重启加载(load)这几步。如下图所示 Redis将在执行写操作命令会将命令追加到 server.aof_buf 缓冲区所有写入命令都将添加到AOF缓存中然后通过 write() 系统调用将aof_buf 缓冲区中数据写入aof文件。此时数据还没有写入硬盘而是复制到内核缓冲区的页面缓存 page cache等待内核将数据写入硬盘内核缓冲区中的数据何时写入硬盘由内核决定。
AOF缓存将根据相应的策略与硬盘同步AOF日志将越来越大就需要定期重写以实现压缩当Redis重新启动时可以加载AOF文件进行数据恢复。 2、AOF数据恢复 AOF文件包含重建Redis数据所需的所有写入命令因此只要重新读入并执行保存在AOF文件中的写入命令Redis就可以恢复Redis关闭前的状态。伪客户端是指 Redis命令只能在客户端的上下文中执行用于加载AOF文件的命令直接来自AOF文件而不是网络连接。因此服务器使用没有网络连接的伪客户端来执行保存在AOF文件中的命令。伪客户端执行命令的效果与具有网络连接的客户端的效果完全相同。
3、AOF三种写回硬盘策略
Redis 3 种写回硬盘的策略说的是在 redis.conf 配置文件中的 appendfsync 配置项可以有以下 3 种参数可填。
Redis将在结束每个事件之前调用 flushAppendOnlyFile() 函数以确定是否需要将AOF缓存中的内容写入并同步到AOF文件。flushAppendOnlyFile() 函数的行为由redis.conf 配置中appendfsync选项的值决定有三个可选值always、everysec和no。
Always同步写回在执行每个写操作命令后AOF日志数据将同步写回硬盘
Everysec每秒写回在执行每个写操作命令后将命令写入AOF文件的内核缓冲区然后每秒将缓冲区的内容写回硬盘
No操作系统控制的回写意味着回写硬盘的时间不受Redis控制而是转移到由操作系统所控制的回写入时间。也就是说在执行每个写操作命令之后该命令首先被写入AOF文件的内核缓冲区然后操作系统决定何时将缓冲区内容写回硬盘。
这三种方法都有缺点Always同步写回如果每次执行后命令都同步到瓷盘中这会影响主线程的性能Everysec每秒回写使用每秒回写一次的频率以避免同步回写的性能开销。虽然它减少了对系统性能的影响但如果发生中断在最后一秒没有中断的命令操作仍将丢失No操作系统控制写回。保存到磁盘的操作由操作系统控制。只要AOF中没有写回命令一旦服务器停机数据就会丢失
三种AOF写回硬盘策略的优缺点写回策略写回时间优点缺点Always同步写回可靠性高最大程度保证安全性性能开销大Everysec每秒写回性能适中宕机时有1秒的数据丢失No操作系统控制的回写性能好宕机存在丢失数据较大
4、AOF重写机制
重写机制就是重写旧日志中的多个命令变为新日志中的一个命令。
假设对列表进行n次修改后一条数据处于“***”状态。只有LPUSH u:list“**” 命令可以恢复数据这为n-1个命令节省了空间AOF重写后日志文件将收缩但将整个数据库的最新数据的操作日志写回磁盘仍然是一个耗时的过程。
重写不会阻塞主线程重写过程由后台线程bgrewriteaof完成这也是为了避免阻塞主线程从而导致数据库性能下降。
Redis设置了一个AOF重写缓冲区该缓冲区将在服务器创建子进程后使用当Redis执行写命令时它将同时向AOF缓冲区和AOF重写缓冲区发送写命令。当子进程完成AOF重写时它将向父进程发送信号。在接收到信号后父进程将调用信号处理函数将AOF重写缓冲区中的所有内容写入新的AOF文件以确保新AOF文件保存的数据库状态与服务器的当前状态一致并重命名新的AOF文件自动覆盖现有AOF文件并完成新旧文件的替换继续处理客户端请求命令。
5、为什么Redis AOF要先执行命令后写日志
Redis在向AOF里面记录日志的时候不会首先检查这些命令。因此如果它先记日志然后执行命令则可能会在日志中记录错误的命令Redis在使用日志恢复数据时可能会出错如果Redis也先写日志然后再操作那么AOF日志中会有许多无效/错误的命令记录。
与MySQL和其他数据库的事务机制相比Redis事务可以称为弱事务。如果事务中发生错误将继续执行。如果事务失败Redis不会回滚对于此类事务将有许多命令无法成功修改数据如果先写日志也会有很多无效的命令。
这两种风险都与AOF写回磁盘的时间有关。如果控制线写命令再写AOF日志就可以解决这两个问题。
四、AOF和RDB对比
RDB持久化AOF持久化全量备份一次保存整个数据库。增量备份一次只保存一个修改数据库的命令。每次执行持久化操作的间隔时间较长。保存的间隔默认为一秒钟Everysec数据保存为二进制格式其还原速度快。使用文本格式还原数据所以数据还原速度一般。执行 SAVE 命令时会阻塞服务器但手动或者自动触发的 BGSAVE 不会阻塞服务器AOF持久化无论何时都不会阻塞服务器。
1、进行数据恢复时既有 dump.rdb文件又有 appendonly.aof 文件应该首先通过appendonly.aof 恢复数据这可以最大程度地确保数据安全。
2、只需要数据备份不太关心一小部分数据的丢失那么可以使用RDB模式RDB文件也易于迁移并放入多个实例中进行数据恢复
五、Redis4.0的混合持久化模式
Redis 4.0的新特性是混合持久化模式混合持久化模式同时使用RDB快照和AOF日志的混合持久模式将RDB文件内容和增量AOF文件内容存储在同一个文件相同的AOF格式文件中可以通过配置参数 aof-use-rdb-preamble 来启用混合持久性模式config get aof-use-rdb-preamble命令进行查看。
由于RDB快照数据和AOF日志数据存储在同一个文件中因此AOF格式文件不再只存储全部AOF日志而是第一部分存储RDB快照第二部分存储从RDB快照持久化开始到持久化结束的增量AOF日志。因此RDB数据通常占大多数AOF日志只是增量日志的一小部分
在混合持久策略下当重新启动下一个Redis实例时首先加载RDB快照的内容然后重放增量AOF日志。这可以取代以前的RDB完全导入或AOF完全重放。
总结
本文为Redis持久化系列第二篇上一篇【Redis】Redis持久化之RDB详解本文讲解兼具广度与深度首先讲解什么是RedisAOF、如何开启AOF持久化深入其AOF的原理AOF持久化实现、AOF数据恢复、AOF三种写回硬盘策略、AOF重写机制解析RedisAOF要先执行命令后写日志以及在实战过程中AOF和RDB对比最后扩展Redis4.0新特性的混合持久化模式。
