Redis之RDB内存快照学习记录

已知AOF是记录每一条写操作命令，之后恢复数据库的时候再把命令都执行一遍。对应的RDB则是记录一瞬间redis数据库的所有数据，以二进制格式记录。这样会恢复的很快。

带来的问题：

1. 对哪些数据做快照？这关系到快照的执行效率问题；
2. 做快照时，数据还能被增删改吗？这关系到 Redis是否被阻塞，能否同时正常处理请求。

对哪些数据做快照，怎么做？

redis的rdb生成是全量快照，也就是说对所有数据进行快照。恢复的时候很快。但是这样生成的时候就会消耗的时间很大。

执行效率就是生成rdb的时候会不会阻塞主线程。主线程被阻塞意味着redis不能正常的执行请求。

redis提供了两个命令：save，在主线程中执行，会导致阻塞；bgsave：创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是
Redis RDB 文件生成的默认配置。

做快照时，数据还能被增删改吗？

可以

redis使用了操作系统提供的写时复制技术，主线程要修改一个数据键值对c
会复制一个该数据的副本，子进程读取该副本，也就是旧的数据。而主线程则可以正常的处理写操作。

redis可以频繁生成快照吗

可以执行，但是会带来巨大的开销

1. 数据大，会对磁盘写带来性能压力
2. fork操作会阻塞主线程

所以rdb缺点就是生成rdb文件的时间不好控制。

redis默认生成rdb配置是：

# 这里是save但是实际上使用的是bgsave
# save 3600 1
# save 300 100
# save 60 10000

# Unless specified otherwise, by default Redis will save the DB:
#   * After 3600 seconds (an hour) if at least 1 key changed
#   * After 300 seconds (5 minutes) if at least 100 keys changed
#   * After 60 seconds if at least 10000 keys changed

# 3600秒中有一次数据修改就生成rdb

redis 4.0 的混合使用 AOF 日志和内存快照

简单来说，内存快照以一
定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。

小结：
RDB，内存快照是记录一瞬间redis中数据的状态，最新数据。记录为二进制格式。

有两种生成方式：save，会阻塞主线程；bgsave：fork一个子进程，然后子进程执行生成rdb的任务。当有新写操作时(修改之前旧的数据)，会采用操作系统的写时复制，保证主线程依旧可以执行写操作。

问题：生成rdb不能过于频繁。fork操作会阻塞主线程。

混合使用AOF和RDB：先记录RDB，再下一次生成RDB时使用AOF。下一次生成之后消除中间生成的AOF。