咔擦,不就是快照嘛
时间:2021-08-19 16:30:42
手机看文章
扫描二维码
随时随地手机看文章
[导读]大家好,我是小林哥。虽说Redis是内存数据库,但是它为数据的持久化提供了两个技术。分别是「AOF日志和RDB快照」。这两种技术都会用各用一个日志文件来记录信息,但是记录的内容是不同的。AOF文件的内容是操作命令;RDB文件的内容是二进制数据。关于AOF持久化的原理我在上一篇已经...
大家好,我是小林哥。虽说 Redis 是内存数据库,但是它为数据的持久化提供了两个技术。分别是「 AOF 日志和 RDB 快照」。这两种技术都会用各用一个日志文件来记录信息,但是记录的内容是不同的。
- AOF 文件的内容是操作命令;
- RDB 文件的内容是二进制数据。
快照怎么用?
要熟悉一个东西,先看看怎么用是比较好的方式。Redis 提供了两个命令来生成 RDB 文件,分别是save
和 bgsave
,他们的区别就在于是否在「主线程」里执行:- 执行了 save 命令,就会在主线程生成 RDB 文件,由于和执行操作命令在同一个线程,所以如果写入 RDB 文件的时间太长,会阻塞主线程;
- 执行了 bgsava 命令,会创建一个子进程来生成 RDB 文件,这样可以避免主线程的阻塞;
save 900 1
save 300 10
save 60 10000
别看选项名叫 sava,实际上执行的是 bgsava 命令,也就是会创建子进程来生成 RDB 快照文件。只要满足上面条件的任意一个,就会执行 bgsava,它们的意思分别是:- 900 秒之内,对数据库进行了至少 1 次修改;
- 300 秒之内,对数据库进行了至少 10 次修改;
- 60 秒之内,对数据库进行了至少 10000 次修改。
执行快照时,数据能被修改吗?
那问题来了,执行 bgsava 过程中,由于是交给子进程来构建 RDB 文件,主线程还是可以继续工作的,此时主线程可以修改数据吗?如果不可以修改数据的话,那这样性能一下就降低了很多。如果可以修改数据,又是如何做到到呢?直接说结论吧,执行 bgsava 过程中,Redis 依然可以继续处理操作命令的,也就是数据是能被修改的。那具体如何做到到呢?关键的技术就在于写时复制技术(Copy-On-Write, COW)。执行 bgsava 命令的时候,会通过fork()
创建子进程,此时子进程和父进程是共享同一片内存数据的,因为创建子进程的时候,会复制父进程的页表,但是页表指向的物理内存还是一个。只有在发生修改内存数据的情况时,物理内存才会被复制一份。这样的目的是为了减少创建子进程时的性能损耗,从而加快创建子进程的速度,毕竟创建子进程的过程中,是会阻塞主线程的。所以,创建 bgsave 子进程后,由于共享父进程的所有内存数据,于是就可以直接读取主线程里的内存数据,并将数据写入到 RDB 文件。当主线程对这些共享的内存数据也都是只读操作,那么,主线程和 bgsave 子进程相互不影响。但是,如果主线程要修改共享数据里的某一块数据(比如键值对 A
)时,就会发生写时复制,于是这块数据的物理内存就会被复制一份(键值对 A'
),然后主线程在这个数据副本(键值对 A'
)进行修改操作。与此同时,bgsave 子进程可以继续把原来的数据(键值对 A
)写入到 RDB 文件。就是这样,Redis 使用 bgsave 对当前内存中的所有数据做快照,这个操作是由 bgsave 子进程在后台完成的,执行时不会阻塞主线程,这就使得主线程同时可以修改数据。细心的同学,肯定发现了,bgsave 快照过程中,如果主线程修改了共享数据,发生了写时复制后,RDB 快照保存的是原本的内存数据,而主线程刚修改的数据,是被办法在这一时间写入 RDB 文件的,只能交由下一次的 bgsave 快照。所以 Redis 在使用 bgsave 快照过程中,如果主线程修改了内存数据,不管是否是共享的内存数据,RDB 快照都无法写入主线程刚修改的数据,因为此时主线程的内存数据和子线程的内存数据已经分离了,子线程写入到 RDB 文件的内存数据只能是原本的内存数据。如果系统恰好在 RDB 快照文件创建完毕后崩溃了,那么 Redis 将会丢失主线程在快照期间修改的数据。另外,写时复制的时候会出现这么个极端的情况。在 Redis 执行 RDB 持久化期间,刚 fork 时,主进程和子进程共享同一物理内存,但是途中主进程处理了写操作,修改了共享内存,于是当前被修改的数据的物理内存就会被复制一份。那么极端情况下,如果所有的共享内存都被修改,则此时的内存占用是原先的 2 倍。所以,针对写操作多的场景,我们要留意下快照过程中内存的变化,防止内存被占满了。RDB 和 AOF 合体
尽管 RDB 比 AOF 的数据恢复速度快,但是快照的频率不好把握:- 如果频率太低,两次快照间一旦服务器发生宕机,就可能会比较多的数据丢失;
- 如果频率太高,频繁写入磁盘和创建子进程会带来额外的性能开销。
aof-use-rdb-preamble yes
混合持久化工作在 AOF 日志重写过程。当开启了混合持久化时,在 AOF 重写日志时,fork
出来的重写子进程会先将与主线程共享的内存数据以 RDB 方式写入到 AOF 文件,然后主线程处理的操作命令会被记录在重写缓冲区里,重写缓冲区里的增量命令会以 AOF 方式写入到 AOF 文件,写入完成后通知主进程将新的含有 RDB 格式和 AOF 格式的 AOF 文件替换旧的的 AOF 文件。也就是说,使用了混合持久化,AOF 文件的前半部分是 RDB 格式的全量数据,后半部分是 AOF 格式的增量数据。这样的好处在于,重启 Redis 加载数据的时候,由于前半部分是 RDB 内容,这样加载的时候速度会很快。加载完 RDB 的内容后,才会加载后半部分的 AOF 内容,这里的内容是 Redis 后台子进程重写 AOF 期间,主线程处理的操作命令,可以使得数据更少的丢失。