你可能不了解的那些事

到标题你可能会说，我知道，不就是RDB和AOF嘛。这些已经是老生常谈了。那么我们今天就深入谈谈这两种持久化方式的逻辑和原理。

RDB的原理

在Redis中RDB持久化的触发分为两种：自己手动触发与Redis定时触发。

针对RDB方式的持久化，手动触发可以使用：

(1)save：会阻塞当前Redis服务器，直到持久化完成，线上应该禁止使用。

(2)bgsave：该触发方式会fork一个子进程，由子进程负责持久化过程，因此阻塞只会发生在fork子进程的时候。

而自动触发的场景如下：

• 根据我们的 save m n 配置规则自动触发;
• 从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发 bgsave;
• 执行 debug reload 时处罚;
• 执行 shutdown时，如果没有开启aof，也会触发。

由于 save 基本不会被使用到，我们来看看 bgsa用fork,现在有了子进程和父进程。

(2)父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制(copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。

(3)当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

PS：fork 操作会阻塞，导致Redis读写性能下降。我们可以控制单个Redis实例的***内存，来尽可能降低Redis在fork时的时间消耗;或者控制自动触发的频率减少fork次数。

AOF的原理

AOF的整个流程大体来看可以分为两步，一步是命令的实时写入(如果是 appendfsync everysec 配置，会有1s损耗)，第二步是对aof文件的重写。

对于增量追加到文件这一步主要的流程是：

(1)命令写入

(2)追加到aof_buf

(3)同步到aof磁盘

那么这里为什么要先写入buf再同步到磁盘呢?如果实时写入磁盘会带来非常高的磁盘IO，影响整体性能。

AOF重写

你可以会想，每一条写命令都生成一条日志，那么AOF文件是不是会很大?答案是肯定的，AOF文件会越来越大，所以Redis又提供了一个功能

（编辑：大同站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!