redis持久化

Redis ⽀持RDB和AOF两种持久化机制持久化功能有效地避免因进程退出造成数据丢失问题 当下次重启时利⽤之前持久化的⽂件即可实现数据恢复RDBRDB持久化是把当前进程数据⽣成快照保存到硬盘的过程触发RDB持久化过程分为⼿动触发和 ⾃动触发触发机制⼿动触发分别对应save和bgsave命令save命令阻塞当前Redis服务器直到RDB过程完成为⽌对于内存⽐较⼤的实例造成⻓时间 阻塞基本不采⽤。bgsave命令Redis进程执⾏fork操作创建⼦进程RDB持久化过程由⼦进程负责完成后⾃动 结束。阻塞只发⽣在fork阶段⼀般时间很短。Redis 内部的所有涉及RDB的操作都采⽤类似bgsave的⽅式除了⼿动触发之外Redis运⾏⾃动触发RDB持久化机制这个触发机制才是在实战中有价值的使⽤save配置。如save m n表⽰m秒内数据集发⽣了n次修改⾃动RDB持久化。从节点进⾏全量复制操作时主节点⾃动进⾏RDB持久化随后将RDB⽂件内容发送给从结点。执⾏shutdown命令关闭Redis时执⾏RDB持久化。图1-1bgsave命令的运作流程执⾏bgsave命令Redis⽗进程判断当前进是否存在其他正在执⾏的⼦进程如RDB/AOF⼦进 程如果存在bgsave命令直接返回。⽗进程执⾏fork创建⼦进程fork过程中⽗进程会阻塞通过infostats命令查 latest_fork_usec 选项可以获取最近⼀次fork操作的耗时单位为微秒。⽗进程fork完成后bgsave命令返回Background saving started信息并不再阻塞⽗进程可 以继续响应其他命令。⼦进程创建RDB⽂件根据⽗进程内存⽣成临时快照⽂件完成后对原有⽂件进⾏原⼦替换。执 ⾏lastsave 命令可以获取最后⼀次⽣成RDB的时间对应info统计 rdb_last_save_time选 项。进程发送信号给⽗进程表⽰完成⽗进程更新统计信息。RDB⽂件的处理保存RDB⽂件保存再dir配置指定的⽬录默认/var/lib/redis/下⽂件名通过dbfilename 配置默认dump.rdb指定。可以通过执⾏configsetdir{new Dir}和config set dbfilename {newFilename} 运⾏期间动态执⾏当下次运⾏时RDB⽂件会保存到新⽬录。压缩Redis默认采⽤LZF算法对⽣成的RDB⽂件做压缩处理压缩后的⽂件远远⼩于内存⼤ ⼩默认开启可以通过参数config set rdbcompression {yes|no} 动态修改。校验如果Redis启动时加载到损坏的RDB⽂件会拒绝启动。这时可以使⽤Redis提供的 redis-check-dump⼯具检测RDB⽂件并获取对应的错误报告虽然压缩RDB会消耗CPU但可以⼤幅降低⽂件的体积⽅便保存到硬盘或通过⽹络发送到 从节点因此建议开启。RDB的优缺点RDB是⼀个紧凑压缩的⼆进制⽂件代表Redis在某个时间点上的数据快照。⾮常适⽤于备份全 量复制等场景。⽐如每6⼩时执⾏bgsave备份并把RDB⽂件复制到远程机器或者⽂件系统中 如hdfs⽤于灾备。Redis加载RDB恢复数据远远快于AOF的⽅式。RDB⽅式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运⾏都要执⾏fork创建⼦进 程属于重量级操作频繁执⾏成本过⾼。RDB⽂件使⽤特定⼆进制格式保存Redis版本演变过程中有多个RDB版本兼容性可能有⻛ 险。AOFAOFAppendOnlyFile持久化以独⽴⽇志的⽅式记录每次写命令重启时再重新执⾏AOF ⽂件中的命令达到恢复数据的⽬的。AOF的主要作⽤是解决了数据持久化的实时性⽬前已经是 Redis 持久化的主流⽅式。理解掌握好AOF持久化机制对我们兼顾数据安全性和性能⾮常有帮助使⽤AOF开启AOF功能需要设置配置appendonlyyes默认不开启。AOF⽂件名通 appendfilename 配置默认是appendonly.aof设置。保存⽬录同RDB持久化⽅式⼀致通过dir 配置指定。AOF的⼯作流程操作命令写⼊append、⽂件同步sync、⽂件重写 rewrite、重启加载load如图1-2所⽰图1-2 AOF⼯作流程所有的写⼊命令会追加到 aof_buf缓冲区中AOF缓冲区根据对应的策略向硬盘做同步操作随着AOF⽂件越来越⼤需要定期对AOF⽂件进⾏重写达到压缩的⽬的当Redis服务器启动时可以加载AOF⽂件进⾏数据恢复AOF过程中为什么需要aof_buf这个缓冲区Redis使⽤单线程响应命令如果每次写AOF⽂件都直 接同步硬盘性能从内存的读写变成IO读写必然会下降。先写⼊缓冲区可以有效减少IO次数同 时Redis还可以提供多种缓冲区同步策略让⽤⼾根据⾃⼰的需求做出合理的平衡⽂件同步Redis 提供了多种AOF缓冲区同步⽂件策略由参数 appendfsync 控制AOF缓冲区同步⽂件策略可配置值说明always命令写⼊aof_buf后调⽤fsync同步完成后返回everysec命令写⼊aof_buf后只执⾏write操作不进⾏ fsync。每秒由同步线程进⾏fsyncno命令写⼊aof_buf后只执⾏write操作由OS控制 fsync 频率系统调⽤write和fsync说明write操作会触发延迟写delayed write机制。Linux在内核提供⻚缓冲区⽤来提供硬盘IO性 能。write操作在写⼊系统缓冲区后⽴即返回。同步硬盘操作依赖于系统调度机制例如缓冲区 ⻚空间写满或达到特定时间周期。同步⽂件之前如果此时系统故障宕机缓冲区内数据将丢失。Fsync针对单个⽂件操作做强制硬盘同步fsync将阻塞直到数据写⼊到硬盘。配置为always时每次写⼊都要同步AOF⽂件性能很差在⼀般的SATA硬盘上只能⽀持⼤ 约⼏百TPS写⼊。除⾮是⾮常重要的数据否则不建议配置。配置为no时由于操作系统同步策略不可控虽然提⾼了性能但数据丢失⻛险⼤增除⾮数据 重要程度很低⼀般不建议配置。配置为everysec是默认配置也是推荐配置兼顾了数据安全性和性能。理论上最多丢失1秒的 数据。重写机制随着命令不断写⼊AOF⽂件会越来越⼤为了解决这个问题Redis引⼊AOF重写机制压缩⽂ 件体积。AOF⽂件重写是把Redis进程内的数据转化为写命令同步到新的AOF⽂件重写后的AOF为什么可以变⼩进程内已超时的数据不再写⼊⽂件。旧的AOF中的⽆效命令例如del、hdel、srem等重写后将会删除只需要保留数据的最终版本多条写操作合并为⼀条例如lpush list a、lpush list b、lpush list c可以合并为lpush list a b c。较⼩的AOF⽂件⼀⽅⾯降低了硬盘空间占⽤⼀⽅⾯可以提升启动Redis时数据恢复的速度。AOF重写过程可以⼿动触发和⾃动触发⼿动触发调⽤ bgrewriteaof 命令⾃动触发根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参数确定⾃动触发时机auto-aof-rewrite-min-size表⽰触发重写时AOF的最⼩⽂件⼤⼩默认为64MBauto-aof-rewrite-percentage代表当前AOF占⽤⼤⼩相⽐较上次重写时增加的⽐例当触发AOF重写时图1-3介绍它的运⾏流程图 1-3 AOF重写流程1. 执⾏AOF重写请求。 5.3) 如果当前进程正在执⾏AOF重写请求不执⾏。如果当前进程正在执⾏bgsave操作重写命令 延迟到bgsave完成之后再执⾏2. ⽗进程执⾏fork创建⼦进程3. 重写a. 主进程fork之后继续响应其他命令。所有修改操作写⼊AOF缓冲区并根据appendfsync策 略同步到硬盘保证旧AOF⽂件机制正确。b. ⼦进程只有fork之前的所有内存信息⽗进程中需要将fork之后这段时间的修改操作写⼊ AOF重写缓冲区中。4. ⼦进程根据内存快照将命令合并到新的AOF⽂件中。5. ⼦进程完成重写a. 新⽂件写⼊后⼦进程发送信号给⽗进程。b. ⽗进程把AOF重写缓冲区内临时保存的命令追加到新AOF⽂件中。c. ⽤新AOF⽂件替换⽼AOF⽂件启动时数据恢复当Redis启动时会根据RDB和AOF⽂件的内容进⾏数据恢复如图1-4所⽰图 1-4 Redis根据持久化⽂件进⾏数据恢复总结Redis 提供了两种持久化⽅案RDB和AOFRDB视为内存的快照产⽣的内容更为紧凑占⽤空间较⼩恢复时速度更快。但产⽣RDB的开 销较⼤不适合进⾏实时持久化⼀般⽤于冷备和主从复制AOF视为对修改命令保存在恢复时需要重放命令。并且有重写机制来定期压缩AOF⽂件RDB和AOF都使⽤fork创建⼦进程利⽤Linux⼦进程拥有⽗进程内存快照的特点进⾏持久化 尽可能不影响主进程继续处理后续命令