Redis持久化：RDB和AOF

猛男看世界

这是第325篇不掺水的，想要了解更多，请戳下方卡片关注我们吧～Redis 数据存储在内存中，如果不想办法将数据保存到硬盘上，一旦Redis重启(退出/故障)，内存的数据将会全部丢失。我们肯定不想 Redis 里的数据由于某些故障全部丢失(导致所有请求都走 MySQL)，即便发生了故障也希望可以将Redis原有的数据恢复过来，这就是持久化的作用。Redis 提供了两种不同的持久化方法来将数据存储到硬盘里边：RDB(Redis Database)，将某一时刻的所有数据保存到一个 RDB 文件中。AOF(append-only-file)，当Redis服务器执行写命令的时候，将执行的写命令保存到 AOF 文件中。RDB内存快照，让宕机快速恢复1.什么是RDB内存快照？在 Redis 执行“写”指令的过程中，内存数据一直会变化，所谓内存快照，指的就是 Redis 内存中数据在某一时刻的状态数据，好比时间定格在某一时刻。当我们拍照时，通过照片就能把某一时刻的瞬间画面完全记录下来。Redis 跟这个类似，就是把某一刻的数据以文件的形式拍下来，写到磁盘上，这个快照文件叫做 RDB 文件，RDB 就是 Redis Database 的缩写。2.生成RDB的策略Redis 并不会在每次执行“写”指令的时候都触发 RDB 写磁盘，只需要在执行内存快照的时候写磁盘，这样既保证了唯快不破，还实现了持久化，宕机快速恢复。我们知道 Redis 的单线程模型决定了我们要尽可能地避免会阻塞主线程的操作，所以就需要尽可能地避免 RDB 文件生成阻塞主线程。为此Redis提供了两个指令用于生成 RDB 文件：SAVE：会阻塞 Redis 服务器进程，服务器不能接收任何请求，直到 RDB 文件创建完毕为止。BGSAVE：fork 出一个子进程，由子进程来负责创建 RDB 文件，服务器进程可以继续接收请求。除了手动调用 SAVE 或者 BGSAVE 命令生成 RDB 文件之外，我们可以使用配置的方式来定期执行：在默认的配置下，如果以下的条件被触发，就会执行 BGSAVE 命令。save9001#在900秒(15分钟)之后，至少有1个key发生变化，save30010#在300秒(5分钟)之后，至少有10个key发生变化save6010000#在60秒(1分钟)之后，至少有10000个key发生变化3.RDB实现原理在RDB执行期间为了保证快照的数据一致性，只能处理读操作，不能修改正在执行快照的数据，这种场景，Redis 是允许的。那 Redis 是如何实现一边处理写请求，同时生成RDB文件的呢？Redis 使用操作系统的多进程写时复制技术 COW（Copy On Write）来实现快照的持久化。Redis 在持久化是会调用glibc 的函数（linux系统中最底层的api）fork产生一个子进程，快照持久化完全交给子进程来处理，父进程继续处理客户端请求。子进程刚刚产生时，它和父进程共享内存里面的代码段和数据段，这时可以将父子进程想象成一个连体婴儿，共享身体。这是Linux操作系统的机制，为了节约内存资源，所以尽可能让它们共享起来，在进程分离的一瞬间，内存的增长几乎没有明显的变化。BGSAVE 子进程可以共享主线程的所有内存数据，读取主线程的数据并写入到 RDB 文件。当主线程执行写指令修改数据的时候，这个数据就会复制一份副本，BGSAVE 子进程读取这个副本数据写到 RDB 文件。在执行 SAVE 或 BGSAVE 命令创建一个新的 RDB 文件时，程序会对数据库中的键进行检查，已过期的键不会被保存到新创建的RDB 文件中。这既保证了快照的完整性，也允许主线程同时对数据进行修改，避免了对正常业务的影响。4.RDB的优缺点优点RDB 文件是一个很简洁的单文件，采用 二进制 + 数据压缩 的方式写磁盘，文件体积小，数据恢复速度快。RDB 的性能很好，需要进行持久化时，主进程会 fork 一个子进程出来，然后把持久化的工作交给子进程，自己不会有相关的I/O操作。缺点RDB 容易造成数据的丢失。假设每5分钟保存一次快照，如果 Redis 因为某些原因不能正常工作，那么从上次产生快照到 Redis 出现问题这段时间的数据就会丢失了。RDB 使用 fork() 产生子进程进行数据的持久化，会阻塞主线程，如果数据比较大的话可能就会花费点时间，造成 Redis 停止服务几毫秒。如果数据量很大且CPU性能不是很好的时候，停止服务的时间甚至会到1秒。另外，过于频繁的执行全量数据快照，有两个严重的性能开销：频繁生成 RDB 文件写入磁盘，磁盘压力过大。可能会出现上一个 RDB 还未完成，下一个又开始生成，陷入死循环。fork 出 BGSAVE 子进程这个动作本身会阻塞主线程，主线程的内存越大，阻塞时间越长。AOF写后日志，避免宕机数据丢失1.什么是AOF写后日志？AOF（Append Only File）写后日志，AOF 持久化就是将修改数据库状态的命令保存到 AOF 文件中，被写入的命令都是以 Redis 的命令请求协议格式保存的，Redis 的命令请求协议是纯文本格式。假设 AOF 日志记录了 Redis 实例创建以来所有的修改指令序列，那么就可以通过一个空的 Redis 实例顺序执行所有的指令，也就是“重放”，来恢复Redis当前实例的内存数据结构的状态。写后日志和写前日志的对比写前日志（WAL，Write Ahead Log）：在实际写数据之前，将修改的数据写到日志文件中，故障恢复得以保证。比如 MySQL Innodb 存储引擎中的 redo log（重做日志）便是记录修改的数据日志，在实际修改数据前先记录修改日志再执行修改数据。写后日志：先执行“写”指令请求，将数据写入内存，再记录日志。日志格式当 Redis 接收到 “set key value” 命令将数据写入到内存之后，会按照如下格式写入 AOF 文件：*3：表示当前指令分为三个部分，每部分都是 “$ + 数字” 开头，紧跟后面是该部分具体的命令、键、值数字：表示这部分的命令、键、值占用的字节大小。比如 “$3” 表示这部分包含三个字节，也就是 set 指令。写后日志的好处写后日志避免了额外的检查开销，不需要对执行的命令进行语法检查。如果使用写前日志的话，就需要先检查语法是否有误，否则日志记录了错误的命令，在使用日志恢复的时候就会报错。另外，写后记录日志，避免了阻塞当前“写”指令的执行。2.写回策略使用 AOF 也不是万无一失的，假如 Redis 刚执行完指令，还没记录日志就宕机了，就有可能丢失这个命令的相关数据；还有，AOF 避免了当前命令的阻塞，但是可能会给下一个命令带来阻塞的风险。AOF 日志是主线程执行的，将日志写入磁盘过程中，如果磁盘压力过大就会导致磁盘写操作很慢，导致后续的“写”指令阻塞。发现了没，这两个问题与磁盘写回有关，如果能合理控制“写”指令执行完后 AOF 日志写回磁盘的时机，问题就可以迎刃而解。为了提高文件的写入效率，当用户调用 write 函数，将一些数据写入到文件时候，操作系统通常会将写入数据暂时保存在一个内存缓冲区里，等到缓冲区的空间被填满或者超过了制定的限制之后，才真正将缓冲区中的数据写入到磁盘里面。这种做法虽然提高了效率，但也为写入数据带来了安全问题，因为如果计算机发生停机，那么保存在内存缓冲区里的写入数据将会丢失。为此系统提供了 fsync 和 fdatasync 两个同步函数，它们可以强制让操作系统立即将缓冲区中的数据写入到硬盘里，从而确保写入数据的安全性。与之相对应 Redis 提供了 AOF 配置项 appendfsync 写回策略来控制 AOF 持久化功能的效率和安全性。appendfsync always #同步写回，写指令执行完毕立即将 aof_buf 缓冲区中的内容写到 AOF 文件。appendfsync everysec #每秒写回，写指令执行完毕，把日志写到 aof_buf 缓冲区，每隔一秒同步到磁盘，该策略为AOF的默认策略。appendfsync no #操作系统控制，写指令执行完毕，把日志写到 aof_buf 缓冲区，由操作系统决定何时写回磁盘。3.AOF重写机制由于 AOF 记录的是一个个指令的内容，这就会导致保存的文件太大，另外，故障恢复的时候需要执行每一个指令，如果日志文件太大，整个恢复过程就会非常慢。为此，Reids 设计了AOF 重写机制，提供了bgrewriteaof命令用于对 AOF 文件进行瘦身。其原理就是开辟一个子进程对内存进行遍历转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件中，序列化完毕后再将操作期间发生的增量 AOF 日志追加到这个新的 AOF 日志文件中，追加完毕后立即替换旧的 AOF 日志文件。瘦身工作就完成了。重写机制有“多变一”的功能，将旧日志中的多条指令，在重写后就变成了一条指令。如下所示：三条 lpush 命令，经过 AOF 重写后生成一条，对于多次修改的场景，缩减效果明显。重写过程和 AOF 日志由主线程写回不同，重写过程实际是由后台子进程 bgrewriteof 完成的，这也是为了避免阻塞主线程，导致性能下降。总的来说，一共出现两个日志，一次内存数据拷贝，分别是旧的 AOF 日志和新的 AOF 重写日志和Redis 数据拷贝。大致流程如下图所示：在上图中，Redis 会将重写过程中接收到的“写”指令操作同时记录到旧的 AOF 缓冲区和新的 AOF 重写缓冲区，这样重写日志也保存了最新的操作，等到拷贝数据的所有操作记录重写完成后，重写缓冲区记录的最新操作也会写到新的 AOF 文件中。每次 AOF 重写时，Redis 会先执行一次内存拷贝，用于遍历数据生成重写记录。防止 AOF 重写过程失败，导致原 AOF 文件被污染，无法做恢复使用。使用两个日志可以保证在重写过程中，新写入的数据不会丢失，并且保持数据的一致性。4.AOF 的优点和缺点优点AOF比RDB可靠。可以灵活制定不同的fsync策略。AOF日志文件是一个纯追加的文件。就算是遇到突然停电的情况，也不会出现日志的定位或者损坏问题。当AOF文件过大时，Redis会自动在后台进行重写。AOF以命令格式存储于文件中，在数据恢复时，AOF文件比RDB文件更容易让开发人员看懂，并加以修改。缺点在相同的数据集下，AOF文件的大小一般会比RDB文件大。在某些fsync策略下，AOF的速度会比RDB慢。通常fsync设置为每秒一次就能获得比较高的性能，而在禁止fsync的情况下速度可以达到RDB的水平。混合日志模型重启 Redis 时，我们很少使用 RDB 来恢复内存状态，因为可能丢失大量数据。通常采用 AOF 日志重放，但是重放 AOF 日志性能相对 RDB 来说要慢很多，在Redis实例很大的情况下，启动需要花费很长时间。Redis 4.0 为了解决这个问题，提供了一个新的持久化选项--混合持久化，将 RDB 文件的内容和增量 AOF 日志文件存放到一起，这里的 AOF 日志不再是全量的日志，而是自持久化开始到持久化结束的这段时间发生的增量 AOF 日志，通常这部分日志很小。在 Redis 重启的时候，先加载 RDB 的内容，然后再重放增量 AOF 日志，这样的操作既保证了 Redis 重启速度，又降低数据丢失风险。总结Redis 提供 RDB 快照持久化方案，记录某一时刻数据状态Redis 通过写时复制技术设计了BGSAVE，避免执行快照期间对读写指令的影响。Redis 提供了 AOF 写后日志持久化方案，记录每一条操作指令。Redis 通过 AOF 重写方案，避免 AOF文件过大。Redis 提供了混合持久化的方案，RDB + AOF 实现持久化保证数据可靠性，同时支持故障后的数据快速恢复。参考Redis设计与实（https://weread.qq.com/web/reader/d35323e0597db0d35bd957bk73532580243735b90b45ac8）Redis核心技术与实战（https://time.geekbang.org/column/intro/329）看完两件事如果你觉得这篇内容对你挺有启发，我想邀请你帮我两件小事1.点个「在看」，让更多人也能看到这篇内容（点了「在看」，bug -1 ）2.关注公众号「政采云技术」，持续为你推送精选好文招贤纳士政采云技术团队（Zero），Base 杭州，一个富有激情和技术匠心精神的成长型团队。规模 500 人左右，在日常业务开发之外，还分别在云原生、区块链、人工智能、低代码平台、中间件、大数据、物料体系、工程平台、性能体验、可视化等领域进行技术探索和实践，推动并落地了一系列的内部技术产品，持续探索技术的新边界。此外，团队还纷纷投身社区建设，目前已经是 google flutter、scikit-learn、Apache Dubbo、Apache Rocketmq、Apache Pulsar、CNCF Dapr、Apache DolphinScheduler、alibaba Seata 等众多优秀开源社区的贡献者。如果你想改变一直被事折腾，希望开始折腾事；如果你想改变一直被告诫需要多些想法，却无从破局；如果你想改变你有能力去做成那个结果，却不需要你；如果你想改变你想做成的事需要一个团队去支撑，但没你带人的位置；如果你想改变本来悟性不错，但总是有那一层窗户纸的模糊……如果你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的自己。如果你希望参与到随着业务腾飞的过程，亲手推动一个有着深入的业务理解、完善的技术体系、技术创造价值、影响力外溢的技术团队的成长过程，我觉得我们该聊聊。任何时间，等着你写点什么，发给 zcy-tc@cai-inc.com