Redis存储（9）Redis的持久化_RDB和AOF

1. RDB持久化Redis数据存储在内存中支持 RDB 和 AOF 两种持久化和 MySQL 里的持久性是一回事把数据存储在硬盘上重启进程 / 主机后数据仍然存在 —— 持久把数据存储在内存上重启进程 / 主机后数据消失 —— 不持久机制持久化功能有效地避免因进程退出造成数据丢失问题当下次重启时利用之前持久化的文件即可实现数据恢复。Redis 为了保证速度快数据肯定还得存储在内存中。但是为了持久化数据还得想办法存储在硬盘上。所以最后决定在内存中和硬盘上都存储数据这样的两份数据在理论上是完全相同的实际上可能存在一个小的概率有差异具体取决于如何进行持久化。当要插入一个新的数据时就需要把这个数据同时写入到内存和硬盘。当查询某个数据时直接从内存中读取硬盘的数据只是在 Redis 重启时用来恢复内存中的数据。代价就是消耗了更多的空间同一份数据存储了两遍但毕竟硬盘价格便宜开销不会带来太大的成本。而且实际上具体怎么写硬盘还有不同的策略是可以保证整体的效率足够高的。假设自己的电脑上有很多的资料虽然现在是把这些资料保存在硬盘上持久化保存但是万一我的电脑出现故障相较于 CPU、显卡、内存来说硬盘是最容易出问题的尤其是机械硬盘。可以拿另一块移动硬盘来作为备份用的硬盘定期备份每个月将电脑硬盘上的资料整体的备份到这个备份盘中— RDB实时备份只要下载了一个新的资料就立即把这份资料往备份盘中拷贝一份— AOFRDBRedis DataBase持久化是把定期的将当前的进程数据生成快照保存到硬盘的过程触发 RDB 持久化过程分为手动触发和自动触发。1.1 RDB触发机制手动触发分别对应save和bgsave命令save 命令阻塞当前 Redis 服务器直到 RDB 过程完成为止对于内存比较大的实例造成长时间阻塞。一般不建议使用bgsavebackground save命令Redis 进程执行 fork 操作创建子进程RDB 持久化过程由子进程负责完成后自动结束。阻塞只发生在 fork 阶段一般时间很短。不会影响 Redis 服务器处理其他客户端的请求和命令。此处 Redis 使用的是 “多进程” 的方式来完成的并发编程来完成 bgsave 的实现Redis 内部的所有涉及 RDB 的操作都采用类似 bgsave 的方式。如果插入新的 key而此时不手动执行 bgsave直接重新启动 Redis 服务器那么刚刚插入的数据在重启之后仍然存在。所以说Redis 生成快照操作不仅仅是手动执行命令才触发也可以自动触发也就是下面的第 3 点。除了手动触发之外Redis 运行自动触发 RDB 持久化机制这个触发机制才是在实战中有价值的。使用 save 配置。如 save m n 表示 m 秒内数据集发生了 n 次修改自动 RDB 持久化。从节点进行全量复制主从复制操作时主节点自动进行 RDB 持久化生成快照随后将 RDB 快照文件内容发送给从节点。如果执行 shutdown 命令service redis-server restart正常关闭关闭 Redis 时或者通过正常流程重新启动 Redis 服务器那么此时 Redis 服务器会在退出时自动执行 RDB 持久化。但如果是异常重启kill -9 或者服务器掉电那么此时 Redis 服务器来不及生成 rdb内存中尚未保存到快照中的数据就会随着重启而丢失。etc/redis/目录下redis的配置文件redis.conf对于 Redis 来说配置文件发生修改后一定要重新启动服务器才能生效。当然如果想要立即生效也可以通过命令的方式进行修改同时满足两个条件即可触发快照的生成/var/lib/redis/目录下有个dump.rdb文件如果把 rdb 文件故意改坏会怎么样手动把 rdb 文件内容改坏如果是通过 service redis-server restart 重启就会在 Redis 服务器退出时重新生成 rdb 快照那么刚才改坏的文件就会被替换掉。而如果是通过 kill 进程的方式再重新启动 Redis 服务器此时 rdb 文件就还是错的。但看起来 Redis 好像没有受到什么影响还是能正常启动能正确获取到 key。那是因为刚才修改的位置应该正好是文件的末尾对前面的内容没有什么影响。但如果是修改了中间位置的内容那么 Redis 服务器就启动不了了。此时Redis 服务器挂了可以看看/var/log/redis/redis-server.log的 Redis 日志了解一下发生了什么。rdb 文件是二进制的如果直接把坏了的 rdb 文件交给 Redis 服务器去使用那么得到的结果是不可预期的。所以Redis 也提供了 rdb 文件的检查工具可以先通过检查工具来检查一下 rdb 文件格式是否符合要求。5.0 版本中检查工具和 Redis 服务器是同一个可执行程序可以在运行时加入不同的选项从而使用其中不同的功能。运行时加入 rdb 文件作为命令行参数那么此时就是以检查工具的方式来运行不会真的启动 Redis 服务器。1.2 RDB流程说明bgsave 是主流的 RDB 持久化方式根据下图来了解它的运作流程。bgsave 命令的运作流程执行 bgsave 命令Redis 父进程Redis 服务器判断当前进是否存在其他正在执行的子进程比如RDB / AOF 子进程如果存在 bgsave 命令直接返回。如果没有其它的工作子进程父进程通过执行 fork 这样的系统调用来创建一个子进程该场景中的绝大部分内存数据是不需要改变的所以在短时间内父进程中不会有大批的内存数据变化因此子进程的 “写时拷贝” 并不会触发很多次fork 过程中父进程会阻塞通过 info stats 命令查看 latest_fork_usec 选项可以获取最近一次 fork 操作的耗时单位为微秒。父进程 fork 完成后bgsave 命令返回 Background saving started 信息并不再阻塞父进程可以继续响应其他命令。子进程创建 RDB 文件根据父进程内存生成临时快照文件完成后对原有文件进行原子替换。执行 lastsave 命令可以获取最后一次生成 RDB 的时间对应 info 统计的 rdb_last_save_time 选项。进程发送信号给父进程表示完成父进程更新统计信息子进程就可以结束销毁了。bgsave 操作流程是创建子进程子进程完成持久化操作持久化速度太快了数据少难以观察到子进程持久化会把数据写入到新的文件中然后使用新的文件替换旧的文件这个容易观察。可以通过 Linux 的 stat 命令来查看文件的 inode 编号这两个文件不再是同一个文件了只不过文件内容是一样的。inode 编号就相当于文件的身份标识。如果是直接使用 save 命令那么此时是不会触发子进程和文件替换逻辑的会直接在当前进程中往刚才的同一文件中写入数据。文件系统典型的组织方式ext4主要是把整个文件系统分成三个大的部分超级块存放一些管理信息inode 区存放 inode 节点每个文件都会分配一个 inode 数据结构包含文件的各种元数据block 区存放文件的数据内容1.3 RDB文件的处理保存RDB 文件把内存中的数据以压缩需要消耗一定的 cpu 资源但是能节省存储空间的形式保存到这个二进制文件中保存在 dir 配置指定的目录默认 /var/lib/redis/下文件名通过 dbfilename 配置默认 dump.rdb指定。可以通过执行 config set dir {newDir} 和 config set dbfilename {newFilename} 运行期间动态执行当下次运行时 RDB 文件会保存到新目录。压缩Redis 默认采用 LZF 算法对生成的 RDB 文件做压缩处理压缩后的文件远远小于内存大小默认开启可以通过参数 config set rdbcompression {yes|no} 动态修改。虽然压缩 RDB 会消耗 CPU但可以大幅降低文件的体积方便保存到硬盘或通过网络发送到从节点因此建议开启。校验如果 Redis 启动时加载到损坏的 RDB 文件会拒绝启动。这时可以使用 Redis 提供的 redis-check-dump 工具检测 RDB 文件并获取对应的错误报告。当执行生成 rdb 镜像操作时此时就会把要生成的快照数据先保存到一个临时文件中。当这个快照生成完毕后再删除之前的 rdb 文件把新生成的临时 rdb 文件名改成刚才的 dump.rdb。也就保证了rdb 文件自始至终只有一个。执行 flushall 命令会自动清除 rdb 文件。1.4 RDB的优缺点RDB的优点RDB 是一个紧凑压缩的二进制文件代表 Redis 在某个时间点上的数据快照。非常适用于备份全量复制等场景。比如每 6 小时执行 bgsave 备份并把 RDB 文件复制到远程机器或者文件系统中如 hdfs用于灾备。Redis 加载 RDB 恢复数据远远快于 AOF 的方式。二进制的方式则直接将数据读取到内存中按照字节的格式取出来放到结构体 / 对象即可文本方式组织数据则需要进行一系列的字符串切分操作RDB的缺点RDB 方式数据没办法做到实时持久化 / 秒级持久化在两次生成快照之间实时数据可能会随着重启而丢失这就导致快照里的数据和当前实时的数据情况可能存在偏差。因为 bgsave 每次运行都要执行 fork 创建子进程属于重量级操作频繁执行成本过高。RDB 文件使用特定二进制格式保存Redis 版本演进过程中有多个 RDB 版本兼容性可能有风险旧版本的 Redis 的 rdb 文件放到新版本的 Redis 中不一定能实现。但一般来说实际工作中 Redis 版本都是统一的实在不行也可以通过写一个程序的方式来直接遍历旧的 Redis 中的所有 key把数据取出来插入到新的 Redis 服务器中即可。2. AOF持久化AOFAppend Only File持久化类似于 MySQL 中的 binlog会把用户的每个操作都记录到文件中以独立日志的方式记录每次写命令重启时再重新执行 AOF 文件中的命令达到恢复数据的目的。AOF 的主要作用是解决了数据持久化的实时性目前已经是 Redis 持久化的主流方式。Redis 重新启动时又读 RDB、又读 AOF到底以哪个为准呢当开启 AOF 时RDB 就不生效了启动的时候就不再读取 rdb 文件内容。2.1 使用 AOF开启 AOF 功能需要设置配置appendonly yes默认是关闭状态。AOF 文件名通过 appendfilename 配置默认是 appendonly.aof设置。先在 /etc/redis/redis.conf里输入 / 搜索append保存目录同 RDB 持久化方式一致通过 dir 配置指定/var/lib/redis。AOF 的工作流程操作命令写入append、文件同步sync、文件重写rewrite、重启加载load如下图所示所有的写入命令会追加到 aof_buf内存中的缓冲区大大降低了写硬盘的次数中。AOF 缓冲区根据对应的策略向硬盘做同步操作。随着 AOF 文件越来越大需要定期对 AOF 文件进行重写达到压缩的目的。当 Redis 服务器启动时可以加载 AOF 文件进行数据恢复。注意写硬盘的时候写入硬盘数据的多少对于性能的影响不是很大但是写入硬盘的次数则影响很大了。硬盘上读写数据顺序读写的速度还是比较快的但还是比内存要慢很多随机访问则速度比较慢。AOF 是每次将新的数据写入到原有文件的末尾属于顺序写入。2.2 命令写入AOF 命令写入的内容直接是文本协议格式。每次进行的操作都会被记录到文本文件中通过一些特殊符号作为分隔符来对命令的细节做出区分。此处遵守 Redis 格式协议Redis 选择文本协议可能的原因文本协议具备较好的兼容性。实现简单。具备可读性。AOF 过程中为什么需要 aof_buf 这个缓冲区Redis 虽然是使用单线程响应命令但是速度很快因为它只是操作内存。引入 AOF 之后又要写内存又要写硬盘同时还要保持之前的速度。实际上这并没有影响到 Redis 处理请求的速度。AOF 机制并非是直接让工作线程把数据写入硬盘而是先写入一个内存中的缓冲区积累一波之后再统一写入。如果每次写 AOF 文件都直接同步硬盘性能从内存的读写变成 IO 读写必然会下降。先写入缓冲区可以有效减少 IO 次数同时Redis 还可以提供多种缓冲区同步刷新策略让用户根据自己的实际情况和需求来做出合理的平衡。如果把数据写入到缓冲区中其本质还是在内存中。万一此时突然进程挂了或者主机掉点了那缓冲区中的数据是否就丢了呢缓冲区中没来得及写入硬盘的数据是会丢失的。缓冲区刷新频率越高性能影响就越大同时数据的可靠性就越高。缓冲区刷新频率越低性能影响就越小同时数据的可靠性就越低。2.3 文件同步Redis 提供了多种 AOF 缓冲区同步文件策略由参数appendfsync控制不同值的含义如下表所示。AOF 缓冲区同步文件策略配置值说明always命令写入 aof_buf 后调用 fsync 同步完成后返回everysec命令写入 aof_buf 后只执行 write 操作不进行 fsync。每秒由同步线程进行 fsync。no命令写入 aof_buf 后只执行 write 操作由 OS 控制 fsync 频率。默认采用 everysec 配置系统调用 write 和 fsync 说明write 操作会触发延迟写delayed write机制。Linux 在内核提供页缓冲区用来提供硬盘 IO 性能。write 操作在写入系统缓冲区后立即返回。同步硬盘操作依赖于系统调度机制例如缓冲区页空间写满或达到特定时间周期。同步文件之前如果此时系统故障宕机缓冲区内数据将丢失。Fsync 针对单个文件操作做强制硬盘同步fsync 将阻塞直到数据写入到硬盘。配置为 always 时每次写入都要同步 AOF 文件性能很差在一般的 SATA 硬盘上只能⽀持大约几百 TPS 写入。除非是非常重要的数据否则不建议配置。配置为 no 时由于操作系统同步策略不可控虽然提高了性能但数据丢失风险大增除非数据重要程度很低一般不建议配置。配置为 everysec是默认配置也是推荐配置兼顾了数据安全性和性能。理论上最多丢失 1s 的数据。2.4 重写机制随着命令不断写入 AOF文件持续增长体积会越来越大会影响到 Redis 下次启动的启动时间Redis 在启动时需要读取 AOF 文件内容该文件记录了中间的过程但实际上 Redis 在重启时只关注最终结果。为了解决这个问题Redis 引入 AOF 重写机制能够针对 AOF 文件进行整理操作剔除其中的冗余操作并合并一些操作以此达到给文件 “瘦身” 的效果压缩文件体积。AOF 文件重写是把 Redis 进程内的数据转化为写命令同步到新的 AOF 文件。重写后的 AOF 为什么可以变小进程内已超时的数据不再写入文件。旧的 AOF 中的无效命令例如 del、hdel、srem 等重写后将会删除只需要保留数据的最终版本。多条写操作合并为一条例如 lpush list a、lpush list b、lpush list 从可以合并为 lpush list a b c。较小的 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 重写时下图介绍它的运行流程。AOF 重写流程执行 AOF 重写请求。如果当前进程正在执行 AOF 重写请求不执行。如果当前进程正在执行 bgsave 操作重写命令延迟到 bgsave 完成之后再执行。父进程执行 fork 创建子进程。重写。a. 父进程 fork 之后继续响应其他命令仍然负责接收客户端的新的请求。父进程还是会把这些请求产生的 AOF 数据先写入到缓冲区中并根据 appendfsync 策略同步到硬盘保证旧 AOF 文件机制正确。b. 子进程只有 fork 之前的所有内存信息父进程中需要将 fork 之后这段时间的修改操作写入 AOF 重写缓冲区中。重写的时候不关心 AOF 文件中原来有什么只关心内存中最终的数据状态。内存中的数据的状态就已经相当于是把 AOF 文件结果整理后的模样了在创建子进程的一瞬间子进程就根据内存快照将命令合并到新的 AOF 文件中也就是继承了当前父进程的内存状态。因此子进程里的内存数据是父进程 fork 之前的状态。fork 后新来的请求对内存造成的修改是子进程感知不到的。此时父进程这里又准备了一个 aof_rewrite_buf 缓冲区专门存放 fork 后收到的数据。子进程完成重写子进程这边把 AOF 新文件数据写入完成后子进程会通过发送信号通知父进程。父进程再把 aof_rewrite_buf 缓冲区中的内容也追加到新 AOF 文件里。用新 AOF 文件代替旧 AOF 文件。此处子进程写数据的过程非常类似于 RDB 生成一个镜像快照只不过 RDB 是按照二进制的方式来生成的AOF 重写则是按照 AOF 这里要求的文本格式来生成的。二者目的都是为了把当前内存中的所有数据状态记录到文件中。如果在执行 bgrewriteaof 的时候发现当前 Redis 已经正在进行 AOF 重写了会怎样呢此时不会再次执行 AOF 重写而是直接返回了。如果在执行 bgrewriteaof 的时候发现当前 Redis 在生成 rdb 文件的快照会怎样呢此时 AOF 重写操作就会等待 rdb 快照生成完毕之后再进行执行 AOF 重写。为什么 RDB 对于 fork 之后的新数据就直接置之不理了呢而不选择采用和 AOF 一样的处理机制呢RDB 本身的设计理念就是用来 “定期备份” 的。只要是定期备份就难以和最新数据保持一致。实时备份不一定就比定期备份更好具体还是要看实际场景需求。现在的系统中系统资源一般都是比较充裕的AOF 的开销并不大所以一般来说AOF 的适用场景更多一些。父进程 fork 完毕之后就已经让子进程写新的 AOF 文件了。并且随着时间的推移子进程很快就写完了新的文件要让新的 AOF 文件代替旧的 AOF 文件。父进程此时还在继续写这个即将消亡的旧的 AOF 文件是否还有意义呢需要考虑到极端情况假设在重写的过程中重写了一半服务器突然挂了此时子进程内存的数据就会丢失新的 AOF 文件内容还不完整所以如果父进程不坚持写旧的 AOF 文件那么重启就无法保证数据的完整性了。AOF 本来是按照文本的方式来写入文件的但是文本的方式来写文件后续加载的成本较高。所以Redis 就引入了 “混合持久化” 的方式结合了 rdb 和 aof 的特点。按照 aof 的方式将每一个请求 / 操作都记录入文件中。在触发 aof 重写之后就会把当前内存的状态按照 rdb 的二进制格式写入到新的 aof 文件中。后续再进行的操作仍然是按照 aof 文本的方式追加到文件后面2.5 启动时数据恢复当 Redis 启动时会根据 RDB 和 AOF 文件的内容进行数据恢复如下图所示。Redis 根据持久化文件进行数据恢复3. RDB 和 AOF 的区别和联系RDB 和 AOF 是 Redis 提供了两种持久化方案。RDB 视为内存的快照产生的内容更为紧凑占用空间较小恢复时速度更快。但产生 RDB 的开销较大不适合进行实时持久化一般用于冷备和主从复制。AOF 视为对修改命令保存在恢复时需要重放命令并且有重写机制来定期压缩 AOF 文件。RDB 和 AOF 都使用 fork 创建子进程利用 Linux 子进程拥有父进程内存快照的特点进行持久化尽可能不影响主进程继续处理后续命令。总结Redis提供了两种持久化方案RDB和AOF。在数据存储方式上RDB通过生成数据库某一时间点的快照文件如dump.rdb来保存整个数据库的状态而AOF则记录所有写命令并以日志形式保存至磁盘。因此在恢复速度方面RDB只需加载一个文件恢复速度更快相比之下AOF需要重放所有命令恢复速度较慢。对于数据完整性RDB可能在两次快照之间丢失数据而AOF允许配置不同的同步策略如always、everysec、no来确保数据的完整性。此外RDB文件相对较小而AOF由于包含所有写操作命令文件通常较大。RDB适用于快速恢复和备份场景而AOF更适合需要高可用性和一致性的实时持久化环境。尽管两者存在明显区别RDB和AOF也有一些共同之处。它们都利用Linux系统中的fork机制创建子进程以此减少对主进程的影响保证主进程能继续处理其他请求。同时这两种方法都可以通过相应的配置文件调整其工作策略例如RDB的自动保存频率以及AOF的不同同步策略。无论是RDB还是AOF都能用于数据恢复——RDB通过加载快照文件AOF则是通过重放日志文件。基于这些特性使用建议是RDB适合那些要求快速恢复且文件大小有限制的情况如备份和冷备AOF则更适用于追求高可靠性和实时数据保护的应用场景。本篇完。下一篇是Redis存储⑩Redis的事务_弱化的原子性。