Redis 两种持久化方式 RDB 和 AOF

快乐的小三菊

已于 2024-06-19 15:06:05 修改

阅读量286

点赞数

分类专栏： redis 文章标签： redis

于 2019-08-12 11:00:46 首次发布

本文链接：https://blog.csdn.net/xhf852963/article/details/99291728

版权

redis 专栏收录该内容

24 篇文章 0 订阅

订阅专栏

一、单节点 Redis 的问题

1.1 存在的问题

1、数据丢失问题：Redis 是内存存储，服务重启可能会丢失数据。

2、并发能力问题：单节点 Redis 并发能力虽然不错，但也无法满足如 618 这样的高并发场景。

3、故障恢复问题：如果 Redis 宕机，则服务不可用，需要一种自动的故障恢复手段。

4、存储能力问题：Redis 基于内存，单节点能存储的数据量难以满足海量数据需求

1.2 解决方案

二、Redis 持久化

2.1 RDB 持久化

2.1.1 简介

RDB 全称 Redis Database Backup file（Redis 数据备份文件），也被叫做 Redis 数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当 Redis 实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为 RDB 文件，默认是保存在当前运行目录。

执行 save 命令会阻塞其他的命令，如下图：

执行 bgsave 命令时则会开启子进程执行备份任务，如下图：

注意：Redis 正常停机时会执行一次 RDB，突然断电啥的则不会执行。

2.1.2 触发机制

Redis 内部有触发 RDB 的机制，可以在 redis.conf 文件中找到，格式如下：

RDB 的其它配置也可以在 redis.conf 文件中设置，如下图：

2.1.3 底层实现

bgsave 开始时会 fork 主进程得到子进程，子进程共享主进程的内存数据。完成 fork 后读取内存数据并写入 RDB 文件。

如下图，首先数据是存在在物理内存上的，而 redis 的主进程如果想要实现对 redis 数据的读写就需要在物理内存上进行读写，而在 linux 环境下，所有的进程都无法直接操作物理内存，而是由操作系统给每个进程分配一个虚拟内存，即主进程只能操作虚拟内存，而操作系统会维护一个虚拟内存和物理内存之间的映射关系表，又称为页表。所以主进程操作虚拟内存，而虚拟内存基于页表的映射关系操作我们的物理内存，这样就实现了对物理内存的读写了。

而当我们执行 fork 操作时，会创建一个子进程，fork 的过程中会把页表做一份拷贝，也就是把映射关系拷贝给子进程，子进程有了和主进程一样的映射关系，当子进程在操作自己的虚拟内存时，一定会操作和主进程一样的物理内存区域，就实现了子进程和主进程之间的内存共享了。

此时，当子进程执行备份操作时，就可以放心的读取自己内存的数据，其实读取的就是主进程的数据。之后再把数据写入到磁盘中新的文件中去。到这为止，异步持久化就实现了。

如果子进程在写 RDB 的过程中，主进程同时在修改数据，此时读与写之间就会有冲突，甚至出现脏数据。为了避免这种事情的发生，fork 的底层采用的是 copy-on-write 技术，当主进程要写的时候做一次拷贝，现在的内存是共享的，没有做拷贝的。此时 fork 会把共享内存标记成 read-only 只读模式，任何一个进程都只能来读数据而不能写。假设此时用户真的来写数据了。此时先拷贝一份数据，再对拷贝的数据完成一份写操作。一旦完成了拷贝，主进程再做读操作的时候也要从拷贝的数据里面读取了，也就是说主进程的页面的映射关系发生了变化。这个就是 copy-on-write 技术。

但是在某些极端的情况下，假设 RDB 写的过程比较慢，耗时较长。就在它写的过程中，不断的有新的请求进来，不断的修改共享的数据，导致所有的数据都被修改了一遍。就会导致所有的数据都需要拷贝一份新的，也就意味着 redis 对内存的占用翻倍了，这是极端的情况，几乎不可能发生，但是理论上有可能。因此 redis 都需要预留一部分内存空间。假设服务器内存为 32G，不能把 32G 都交给 redis，还需要预留一部分。