redis数据持久化

redis是一个即可当做缓存使用，也可进行持久化的远程字典服务。今天我们来谈谈redis的数据持久化；

了解过redis的同学都知道，redis有两种数据持久化方案，aof方式和rdb方式；这两种方式可以同时存在于同一个redis服务实例中，并不相互排斥；

1、rdb方式，是一种全量数据文件同步的方式；在配置文件中使用save关键字进行配置，每一个save项表示一个持久化条件，可以同时设置多个条件，只要满足条件中的一个就会进行数据持久化（整个数据库）；

save配置项参数为：save 时间(秒)  次数；即在给定的时间内，数据至少修改了给定的次数，就进行数据持久化；

如图，在上面配置中，有三个save配置项，说明该实例配置了三个触发rdb进行持久化的条件；在这三个给定的条件中，只需要满足一个，就进行一次数据持久化。

2、aof方式，该方式是实时数据持久化方式，该方式进行持久化的不是数据本身，而是进行数据库数据修改的语句，redis会将对数据库进行数据修改的操作记录到持久化文件当中；如果某一个redis实例的处理量特别大，当进行aof持久化的时候，会导致持久化文件相当的大，为了防止aof持久化文件特别大，aof支持进行持久化文件重写，即redia会将数据库中的数据转为写指令存入新的AOF文件时，记录的只是每个数据的最后一次写指令，这种方式可以有效的减小aof持久化文件的大小。

    rdb方式和aof重写方式，都是采用子进程的方式进行的，不知道，大家有没有想过，redis为什么采用该方式进行数据的持久化？

    大家都知道，redis是单线程工作的(单线程为用户提供服务，实际后台还存在其他线程在运行)；而所有的程序，为了保证数据的安全，在同一时刻只允许一个线程对其进行修改，如果采用多线程模式进行数据持久化，那么需要增加锁机制，而锁机制是一个系统调用，需要消耗一定的性能。采用多进程方式，设计者巧妙的利用了copy-on-write机制，即减少了程序中数据的拷贝，有不需要使用锁来进行数据安全保护。

    但是使用多进程模式进行数据持久化，还会带来另一个问题，那就是，当子进程进程数据持久化的时候，主进程还在持续的为用户提供服务，如果这个时候用户请求中有一条是进行数据修改的操作，而由于多进程中，各个进程的大家的内存地址空间是相互独立的，主进程的数据库的数据能够正常的被修改，但是子进程的数据库，不会被修改，那这个时候，我们该怎样将修改的数据通知给子进程呢？

    其实，该问题仅仅会在进行aof文件重写的时候才会遇到；而在再行rdb文件持久化的时候，该问题是不存在的，那是由于rdb模式，是满足条件的数据持久化模式，对数据的准确度要求并不是那么的高，而且在进行rdb持久化的时候，aof持久化任然在主进程中执行。

    如上图所示，为redis进行数据持久化的活动图，上图展示了主进程进行rdb数据持久化和进行aof重写时候的流程；从上图可以看出来，在进行aof重写的时候，主进程将进行数据修改的语句会写到管道中，子进程去管道中将数据读取出来；进行aof重写的时候，redis主子进程如何进行通信的呢？

    如上图所示，主进程在创建aof重写子进程的时候，创建了三对通信管道，其中主进程通过f1句柄，将用户修改数据库的操作语句写入管道中，子进程通过f0句柄将操作读取出来；子进程在redis数据库中的数据全部重写完成后，通过f3句柄告知主进程，不要在将用户修改数据库的语句写入管道中，主进程通过f2句柄读取到之后，通过f5句柄写回响应，子进程通过f4句柄将响应读取出来；至此整个aof重写完成，子进程退出；