如何看还在建设的网站,成都建设网官方网站,hao123网站用什么程序做的,手机优化软件#x1f9d1; 博主简介#xff1a;CSDN博客专家#xff0c;历代文学网#xff08;PC端可以访问#xff1a;https://literature.sinhy.com/#/literature?__c1000#xff0c;移动端可微信小程序搜索“历代文学”#xff09;总架构师#xff0c;15年工作经验#xff0c;… 博主简介CSDN博客专家历代文学网PC端可以访问https://literature.sinhy.com/#/literature?__c1000移动端可微信小程序搜索“历代文学”总架构师15年工作经验精通Java编程高并发设计Springboot和微服务熟悉LinuxESXI虚拟化以及云原生Docker和K8s热衷于探索科技的边界并将理论知识转化为实际应用。保持对新技术的好奇心乐于分享所学希望通过我的实践经历和见解启发他人的创新思维。在这里我希望能与志同道合的朋友交流探讨共同进步一起在技术的世界里不断学习成长。 技术合作请加本人wx注明来自csdnforeast_sea 全解Redis RDB持久化和AOF持久化
在当今数据驱动的时代数据的安全性与可靠性是任何系统都不容忽视的关键要素。Redis 作为一款广泛应用的高性能内存数据库其数据持久化机制尤为重要。
持久化简单来说就是将内存中的数据以某种形式保存到磁盘等持久存储介质上的过程。Redis 之所以需要持久化是因为内存数据具有易失性。一旦服务器遭遇意外断电、系统故障或其他突发情况若没有持久化机制内存中的数据将瞬间丢失这对于依赖 Redis 存储关键信息的应用来说可能是灾难性的打击。
Redis 实现持久化主要通过 RDB 和 AOF 两种方式。RDB 持久化采用定期快照的策略在特定的时间点将 Redis 数据集的全量数据以二进制的形式保存到磁盘。这种方式在数据恢复时速度较快适合用于大规模数据的备份与恢复场景且生成的 RDB 文件相对紧凑便于传输与存储。
而 AOF 持久化则是基于日志记录的方式它会将 Redis 执行的写命令以追加的形式记录到 AOF 文件中。这样在恢复数据时只需重新执行这些写命令即可重建数据集。AOF 持久化的优势在于它能够提供更精细的数据恢复粒度数据丢失风险相对较低并且可以通过配置不同的刷盘策略来平衡数据安全性与性能。
本文将深入剖析 Redis 的 RDB 持久化和 AOF 持久化详细探讨它们各自的工作原理、实现细节以及优缺点帮助读者全面理解这两种持久化机制从而在实际使用 Redis 时能够根据具体的应用场景与需求合理地选择和配置持久化策略确保数据的安全性与系统的稳定性。 文章目录 全解Redis RDB持久化和AOF持久化什么是持久化Redis为什么要持久化Redis如何实现持久化RDB持久化AOF持久化RDB和AOF的优缺点 什么是持久化
持久化Persistence即把数据如内存中的对象保存到可永久保存的存储设备中如磁盘。持久化的主要应用是将内存中的对象存储在数据库中或者存储在磁盘文件中、XML数据文件中等等。 还可以从如下两个层面简单的理解持久化
应用层如果关闭(shutdown)你的应用然后重新启动则先前的数据依然存在。系统层如果关闭(shutdown)你的系统电脑然后重新启动则先前的数据依然存在。
Redis为什么要持久化
Redis是内存数据库为了保证效率所有的操作都是在内存中完成。数据都是缓存在内存中当你重启系统或者关闭系统之前缓存在内存中的数据都会丢失再也不能找回。因此为了避免这种情况Redis需要实现持久化将内存中的数据存储起来。
Redis如何实现持久化
Redis官方提供了不同级别的持久化方式
RDB持久化能够在指定的时间间隔能对你的数据进行快照存储。AOF持久化记录每次对服务器写的操作当服务器重启的时候会重新执行这些命令来恢复原始的数据AOF命令以redis协议追加保存每次写的操作到文件末尾。Redis还能对AOF文件进行后台重写使得AOF文件的体积不至于过大。不使用持久化如果你只希望你的数据在服务器运行的时候存在你也可以选择不使用任何持久化方式。同时开启RDB和AOF你也可以同时开启两种持久化方式在这种情况下当redis重启的时候会优先载入AOF文件来恢复原始的数据因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
这么多持久化方式我们应该怎么选在选择之前我们需要搞清楚每种持久化方式的区别以及各自的优劣势。
RDB持久化
RDB(Redis Database)持久化是把当前内存数据生成快照保存到硬盘的过程触发RDB持久化过程分为手动触发和自动触发。
1手动触发
手动触发对应save命令会阻塞当前Redis服务器直到RDB过程完成为止对于内存比较大的实例会造成长时间阻塞线上环境不建议使用。
2自动触发
自动触发对应bgsave命令Redis进程执行fork操作创建子进程RDB持久化过程由子进程负责完成后自动结束。阻塞只发生在fork阶段一般时间很短。
在redis.conf配置文件中可以配置
save seconds changes表示xx秒内数据修改xx次时自动触发bgsave。 如果想关闭自动触发可以在save命令后面加一个空串即
save 还有其他常见可以触发bgsave如
如果从节点执行全量复制操作主节点自动执行bgsave生成RDB文件并发送给从节点。默认情况下执行shutdown命令时如果没有开启AOF持久化功能则 自动执行bgsave。
bgsave工作机制 1执行bgsave命令Redis父进程判断当前是否存在正在执行的子进 程如RDB/AOF子进程如果存在bgsave命令直接返回。
2父进程执行fork操作创建子进程fork操作过程中父进程会阻塞通 过info stats命令查看latest_fork_usec选项可以获取最近一个fork操作的耗时单位为微秒
3父进程fork完成后bgsave命令返回“Background saving started”信息并不再阻塞父进程可以继续响应其他命令。
4子进程创建RDB文件根据父进程内存生成临时快照文件完成后对原有文件进行原子替换。执行lastsave命令可以获取最后一次生成RDB的 时间对应info统计的rdb_last_save_time选项。
5进程发送信号给父进程表示完成父进程更新统计信息具体见 info Persistence下的rdb_*相关选项。
AOF持久化
AOFappend only file持久化以独立日志的方式记录每次写命令 重启时再重新执行AOF文件中的命令达到恢复数据的目的。AOF的主要作用是解决了数据持久化的实时性目前已经是Redis持久化的主流方式。
AOF持久化工作机制
开启AOF功能需要配置appendonly yes默认不开启。
AOF文件名 通过appendfilename配置设置默认文件名是appendonly.aof。保存路径同 RDB持久化方式一致通过dir配置指定。
AOF的工作流程操作命令写入 append、文件同步sync、文件重写rewrite、重启加载 load。 1所有的写入命令会追加到aof_buf缓冲区中。
2AOF缓冲区根据对应的策略向硬盘做同步操作。
AOF为什么把命令追加到aof_buf中Redis使用单线程响应命令如果每次写AOF文件命令都直接追加到硬盘那么性能完全取决于当前硬盘负载。先写入缓冲区aof_buf中还有另一个好处Redis可以提供多种缓冲区同步硬盘的策略在性能和安全性方面做出平衡。
3随着AOF文件越来越大需要定期对AOF文件进行重写达到压缩的目的。
4当Redis服务器重启时可以加载AOF文件进行数据恢复。
AOF重写rewrite机制
重写的目的
减小AOF文件占用空间更小的AOF 文件可以更快地被Redis加载恢复。
AOF重写可以分为手动触发和自动触发
手动触发直接调用bgrewriteaof命令。自动触发根据auto-aof-rewrite-min-size和auto-aof-rewrite-percentage参数确定自动触发时机。
auto-aof-rewrite-min-size表示运行AOF重写时文件最小体积默认 为64MB。
auto-aof-rewrite-percentage代表当前AOF文件空间 aof_current_size和上一次重写后AOF文件空间aof_base_size的比值。
自动触发时机
当aof_current_sizeauto-aof-rewrite-minsize 并且aof_current_size-aof_base_size/aof_base_sizeauto-aof-rewritepercentage。
其中aof_current_size和aof_base_size可以在info Persistence统计信息中查看。 AOF文件重写后为什么会变小
1旧的AOF文件含有无效的命令如del key1 hdel key2等。重写只保留最终数据的写入命令。
2多条命令可以合并如lpush list alpush list blpush list c可以直接转化为lpush list a b c。
AOF文件数据恢复 数据恢复流程说明
1AOF持久化开启且存在AOF文件时优先加载AOF文件。
2AOF关闭或者AOF文件不存在时加载RDB文件。
3加载AOF/RDB文件成功后Redis启动成功。
4AOF/RDB文件存在错误时Redis启动失败并打印错误信息。
RDB和AOF的优缺点
RDB优点
RDB 是一个非常紧凑的文件,它保存了某个时间点的数据集,非常适用于数据集的备份,比如你可以在每个小时报保存一下过去24小时内的数据,同时每天保存过去30天的数据,这样即使出了问题你也可以根据需求恢复到不同版本的数据集。RDB 是一个紧凑的单一文件,很方便传送到另一个远端数据中心非常适用于灾难恢复。RDB 在保存 RDB 文件时父进程唯一需要做的就是 fork 出一个子进程,接下来的工作全部由子进程来做父进程不需要再做其他 IO 操作所以 RDB 持久化方式可以最大化 Redis 的性能。与AOF相比,在恢复大的数据集的时候RDB 方式会更快一些。
AOF优点 你可以使用不同的 fsync 策略无 fsync、每秒 fsync 、每次写的时候 fsync .使用默认的每秒 fsync 策略, Redis 的性能依然很好( fsync 是由后台线程进行处理的,主线程会尽力处理客户端请求),一旦出现故障你最多丢失1秒的数据。 AOF文件是一个只进行追加的日志文件,所以不需要写入seek,即使由于某些原因(磁盘空间已满写的过程中宕机等等)未执行完整的写入命令,你也也可使用redis-check-aof工具修复这些问题。 Redis 可以在 AOF 文件体积变得过大时自动地在后台对 AOF 进行重写 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的因为 Redis 在创建新 AOF 文件的过程中会继续将命令追加到现有的 AOF 文件里面即使重写过程中发生停机现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕Redis 就会从旧 AOF 文件切换到新 AOF 文件并开始对新 AOF 文件进行追加操作。 AOF 文件有序地保存了对数据库执行的所有写入操作 这些写入操作以 Redis 协议的格式保存 因此 AOF 文件的内容非常容易被人读懂 对文件进行分析parse也很轻松。 导出export AOF 文件也非常简单 举个例子 如果你不小心执行了 FLUSHALL 命令 但只要 AOF 文件未被重写 那么只要停止服务器 移除 AOF 文件末尾的 FLUSHALL 命令 并重启 Redis 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
RDB缺点
Redis 要完整的保存整个数据集是一个比较繁重的工作,你通常会每隔5分钟或者更久做一次完整的保存,万一在 Redis 意外宕机,你可能会丢失几分钟的数据。RDB 需要经常 fork 子进程来保存数据集到硬盘上,当数据集比较大的时候, fork 的过程是非常耗时的,可能会导致 Redis 在一些毫秒级内不能响应客户端的请求。
AOF缺点
对于相同的数据集来说AOF 文件的体积通常要大于 RDB 文件的体积。数据恢复load时AOF比RDB慢通常RDB 可以提供更有保证的最大延迟时间。
RDB和AOF简单对比总结
RDB优点
RDB 是紧凑的二进制文件比较适合备份全量复制等场景RDB 恢复数据远快于 AOF
RDB缺点
RDB 无法实现实时或者秒级持久化新老版本无法兼容 RDB 格式。
AOF优点
可以更好地保护数据不丢失appen-only 模式写入性能比较高适合做灾难性的误删除紧急恢复。
AOF缺点
对于同一份文件AOF 文件要比 RDB 快照大AOF 开启后会对写的 QPS 有所影响相对于 RDB 来说 写 QPS 要下降数据库恢复比较慢 不合适做冷备。
