2. Redis持久化、主从哨兵架构详解

本文是按照自己的理解进行笔记总结，如有不正确的地方，还望大佬多多指点纠正，勿喷。

课程内容：

1、RDB、AOF及混合持久化详解

2、并行持久化之写时复制机制详解

3、Redis主从架构原理详解

4、Redis管道及lua脚本详解

5、Redis哨兵高可用架构详解

1. Redis持久化

1.1 RDB快照(snapshot)

在默认情况下， Redis 将内存数据库快照保存在名字为 dump.rdb 的二进制文件中。

你可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时， 自动保存一次 数据集。

比如说， 以下设置会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次 数据集：

# save 60 1000 //关闭RDB只需要将所有的save保存策略注释掉即可

我们可以打开redis.conf文件进去看一下：

文件持久化的位置如下：

还可以手动执行命令生成RDB快照，进入redis客户端执行命令save或bgsave可以生成dump.rdb文件，每次命令执行都会将所有redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。

1.1.1 bgsave的写时复制(COW)机制

rdb这种快照文件，redis在写命令，突然触发了我们所配置的条件，做持久化了。如果一下是8G的内存，把这8G写到dump.rdb文件里去，是有可能阻塞我们的正常redis请求。是有可能的。

redis内部对这个持久化rdb文件有两种策略，在后台执行那种save命令。save命令是一个同步操作，是后台做的操作。使用save是会阻塞客户端的新的请求过来。save这种是主线程直接操作。还有一种方式，也是redis经常使用的一种方式就是bgsave

Redis 借助操作系统提供的写时复制技术（Copy-On-Write, COW），在生成快照的同时，依然可以正常处理写命令。简单来说，bgsave 子进程是由主线程 fork 生成的，可以共享主线程的所有内存数据。

bgsave 子进程运行后，开始读取主线程的内存数据，并把它们写入 RDB 文件。此时，如果主线程对这些数据也都是读操作，那么，主线程和 bgsave 子进程相互不影响。但是，如果主线程要修改一块数据，那么，这块数据就会被复制一份，生成该数据的副本。然后，bgsave 子进程会把这个副本数据写入 RDB 文件，而在这个过程中，主线程仍然可以直接修改原来的数据。

save与bgsave对比：

命令	save	bgsave
Io类型	同步	异步
是否阻塞redis其它命令	是	否(在生成子进程执行调用fork函
复杂度	o(n)	o(n)
优点	不会消耗额外内存	不阻塞客户端命令
缺点	阻塞客户端命令	需要fork子进程，消耗内存