17.Redis系列之快照RDB方式持久化

本文学习redis两大持久化技术之一：RDB（redis database）快照方式持久化备份与还原，以及RDB方式的优缺点

1. RDB相关配置

首先我们先简单了解下Redis7中RDB相关配置

// save <seconds> <changes> [<seconds> <changes> ...]
// 默认配置1小时至少1个key、15分钟60个key、1分钟1W个key变动会进行RDB快照操作
save 3600 1 300 100 60 10000
// 当快照保存失败时禁止redis写入key,一般都是磁盘空间满，与ES类似
stop-writes-on-bgsave-error yes
// 采用LZF算法【对重复值压缩，通过hash表判重】压缩.rdb快照文件
rdbcompression yes
// 采用CRC64算法检查.rdb文件完整性
rdbchecksum yes
// RDB快照文件名称
dbfilename dump.rdb
// RDB快照文件存储目录
dir ./

2. RDB快照还原实践

redis启动后，未进行任何操作截图

通过代码我们写入10100条数据

@SpringBootTest
public class RedisTest {

    @Autowired
    private RedissonClient redissonClient;

    @Test
    public void testRdb() throws InterruptedException {
        RMap<String, String> rMap = redissonClient.getMap("rdb");
        for (int i = 0; i < 10020; i++) {
            rMap.put(i + "", i + "");
        }
        Thread.sleep(60000);
        for (int i = 0; i < 80; i++) {
            rMap.put(i + "ok", i + "ok");
        }
    }
}

由图可以看到，RDB快照已生成，hkeys rdb可以看到有10100个key

我们将生成dump.rdb文件重命名为dump.rdb.bak作为模拟备份文件
执行以下命令后，可以看到系统又重新生成了dump.rdb文件

127.0.0.1:6379> flushdb
OK
127.0.0.1:6379> shutdown

现在我们删除dump.rdb文件，并将dump.rdb.bak改为dump.rdb模拟快照还原后启动redis，执行hkeys rdb可以看到只有10020个key在快照中保存了下来

由此我们验证了：1分钟1W个key变动会进行RDB快照,因为1-10020个key是在一分钟内的操作，所以RDB快照保存了下来，而对于10021-10100的key操作是在下一个分钟内的操作，未满足变动条件不进行RDB快照，所以宕机后还原RDB快照后我们发现它们丢失了

对于未满足变动条件的我们可以手工执行来备份

# 异步非阻塞方式备份
127.0.0.1:6379> bgsave
Background saving started
# 同步阻塞方式备份【慎用】
127.0.0.1:6379> save
OK

3. RDB快照流程

在bgsave的时候，采用fork+copyonwrite[写时拷贝技术]技术。fork()是linux的api，用于创建一个子进程。fork()出来的进程共享其父类的内存数据，仅仅是共享fork()出子进程的那一刻的内存数据，后期主进程修改数据对子进程不可见。
主进程fork()子进程之后，内核把主进程中所有的内存页的权限都设为read-only，然后子进程的地址空间指向主进程。这也就是共享了主进程的内存，当主进程写内存时(肯定是主进程写，因为子进程只负责rdb文件持久化工作，不参与客户端的请求)，CPU硬件检测到内存页是read-only的，于是触发页异常中断（page-fault），陷入内核的一个中断例程。中断例程中，内核就会把触发的异常的页复制一份（这里仅仅复制异常页，也就是所修改的那个数据页，而不是内存中的全部数据），于是主子进程各自持有独立的一份
copyonwrite总结: fork()出来的子进程共享主进程的物理空间，当主进程有内存写入操作时，read-only内存页发生中断，将触发异常的内存页复制一份(其余的页还是共享主进程的)从而主进程可写，而子进程继续进行老数据的RDB快照

4. RDB快照优缺点

优点：

• fork+copyonwrite技术，rdb快照不影响redis主进程
• 适合大规模数据恢复，恢复速度快
• 适合对数据完整性与一致性要求不高场景
• 节省磁盘空间

缺点：

• fork后，对于写时拷贝技术，海量数据修改比较消耗性能
• redis宕机后，在最后一次快照后的所有修改会丢失

欢迎关注公众号 算法小生 与我沟通交流