Redis提供了两种持久化方式：RDB和AOF，下面，我们来看看上述两者的底层实现原理。
一，RDB持久化 1.RDB文件的创建与载入在Redis中，有两种方式可以生成RDB文件，一个是SAVE，另一个是BGSAVE
两者的主要区别是：SAVE命令在进行持久化操作的过程中，会阻塞Redis服务进行，也就是说，在以SAVE方式进行持久化操作的过程中，服务器不能再处理其他的命令请求，这个请求过程必须等到持久化操作结束；BGSAVE命令则是单独开启一个子进程来处理持久化操作。
上述过程用伪代码表现形式如下：
def save():
rdbSave() # 将数据写入文件操作
def bgsave():
# 创建子进程 pid = fork()
if pid == 0:
# 子进程负责创建RDB文件 rdbSave()
# 完成之后向父进程发送信号 signal_parent()
elif pid > 0:
# 父进程继续处理命令请求，并通过轮询等待子进程信号 handle_request_and_wait_signal()
else:
# 处理出错情况 handle_fork_error()
RDB文件的载入是在Redis服务器启动时，自动载入的，所以Redis并没有专门用于载入RDB文件的命令。只要服务器检测到有RDB文件的存在，它就会自动进行载入 操作。
关于RDB文件载入过程，值得提一下就是，如果服务器开启了AOF持久化功能，那么服务器会优先使用AOF文件来还原数据库。
只有在AOF持久化功能处于关闭状态，Redis服务器才会使用RDBRDB文件来还原数据库状态。
2.执行save,bgsave命令时，服务器的状态在执行save命令时，redis服务器会被阻塞，所以当save命令正在被执行时，客户端发送的所有命令请求都会被拒绝。
在执行bgsave命令时，由于是子进程在处理持久化操作，所以Redis服务器可以继续处理客户的命令请求。但是，在执行bgsave命令期间，如果客户端又发送来了save,bgsave,bgrewrteaof三个命令其中一个，那么服务器的处理方式会有所不同。
首先，bgsave 命令正在被子进程执行，那么客户端发来的save命令会直接被服务器拒绝，这是为了避免父进程与子进程同时执行两个rdbSave()调用，防止产生竞争条件。
其次，bgsave 命令正在被子进程执行，那么客户端发来的bgsave命令也会直接被服务器拒绝，同样也是为了防止产生竞争条件。
最后，bgsave命令和bgrewrteaof命令不能同时进行，如果bgsave命令正在执行，客户端的bgrewrteaof命令会延迟到bgsave命令执行完毕以后才会执行；如果bgrewrteaof命令正在被执行，那么客户端的bgsave命令会直接被服务器拒绝。这是因为，这两个命令都是由子进程来执行的，不能同时执行主要考虑到性能问题，试想两个并发执行的命令，同时进行大量的读写磁盘操作，这会大大降低服务器性能。
3.间隔性保存上述我们讲到，save命令会阻塞服务器进程，而bgsave命令则会另启一个进程来执行持久化操作。
因为bgsave命令可以在不阻塞服务器进程来进行持久化，所以redis允许用户通过设置服务器配置的save选项，来让redis间接性的自动执行bgsave命令。
用户可以在redis.conf文件配置save保存规则，只要其中一个条件满足，服务器就会自动执行bgsave命令。
save 900 1 # 900秒之内，对数据库进行了一次修改就执行bgsave命令
save 300 10 # 300秒之内，对数据库进行了十次修改就执行bgsave命令
save 60 10000 # 60秒之内，对数据库进行了一万次修改就执行bgsave命令 接下来，我们来看看服务器是如何根据上述配置的规则，自动执行bgsave命令。
我们来看看源码redis.h/redisServer，在这个大的结构体中存在如下一个字段：
struct redisServer{
...
struct saveparam *saveparams; //记录了保存条件的数组
...
};
服务器会根据save选项所设置的保存条件，将该值设置到服务器redisServer结构的saveparams属性：
saveparams属性是一个数组，数组每一个元素都是一个saveparam结构，每个结构都保存了一个save选择设置的保存条件：
struct saveparam{
//秒数
time_t seconds;
//修改数
int changes;
};
上述结构体中的两个参数就是我们设置的，如：save 600 1; 那么seconds=600,changes=1。是不是很神奇！！
如果有多个条件同时存在的话，那么它的结构如下：
除了saveparms数组之外，服务器还维持着两个参数：dirty和lastsave.
其中，dirty记录上一次执行save或者bgsave命令，服务器对数据库状态进行了多少次修改。lastsave则记录上一次执行save或者bgsave命令的时间。
struct redisServer{
// 修改计数器 long long dirty;
// 上一次执行保存的时间 time_t lastsave;
struct saveparam *saveparams; //记录了保存条件的数组};
说完了上述，接下来就来说说，redis服务器是如何发现该执行保存操作呢？