redis第五讲 内存快照

redis第五讲

正因为记录的是操作命令，而不是实际的数据，所以，用 AOF 方法进行故障恢复 的时候，需要逐一把操作日志都执行一遍。如果操作日志非常多，Redis 就会恢复得很慢。
RDB：
和 AOF 相比，RDB 记录的是某一时刻的数据，并不是操作，所以，在做数据恢复时，我 们可以直接把 RDB 文件读入内存，很快地完成恢复。
给哪些数据做快照？
Redis 的数据都在内存中，为了提供所有数据的可靠性保证，它执行的是全量快照，也就 是说，把内存中的所有数据都记录到磁盘
会阻塞主线程吗？
Redis 提供了两个命令来生成 RDB 文件，分别是 save 和 bgsave。
save:在主线程中执行，会导致阻塞;
bgsave:创建一个子进程，专门用于写入 RDB 文件，避免了主线程的阻塞，这也是 Redis RDB 文件生成的默认配置。
快照时数据能被修改吗？
可以。写时复制技术：如果主线程要修改一块数据(例如图中的键值对 C)， 那么，这块数据就会被复制一份，生成该数据的副本。
多久做一次快照？
太慢：数据有丢失风险。
太快：
一方面，频繁将全量数据写入磁盘，会给磁盘带来很大压力
另一方面，bgsave 子进程需要通过 fork 操作从主线程创建出来。ork 这个创建过程本身会阻塞主线程，而且主线程的内存越 大，阻塞时间越长。如果频繁 fork 出 bgsave 子进程，这就会频繁阻塞主线程了。
解决办法：
Redis 4.0 中提出了一个混合使用 AOF 日志和内存快照的方法。简单来说，内存快照以一 定的频率执行，在两次快照之间，使用 AOF 日志记录这期间的所有命令操作。等到第二次做全量快照时，就可 以清空 AOF 日志。

• 增量快照：只记录针对上次全量快照修改的地方。坏处：需要使用额外的元数据信息去记录哪些数据被修改，会带来额外的空间开销问题。