一、快照 RDB

（1）、介绍

    redis 持久化的RDB文件是经过压缩的二进制文件，保存了内存中的键值对数据，存在硬盘里，防止redis数据库出现故障时数据丢失。

    当redis数据库出现故障时，可以使用RDB文件进行还原为原先的数据库状态。

    在实际运用中，一定要设置好规则进行定期的备份redis服务器数据，保存在其他异地服务器，一旦redis数据库出现问题，想还原为原先的时间点，就可以使用备份RDB文件进行还原。

    如果RDB文件有问题，还可以使用redis数据库自带的工具redis-check-dump进行检测。

（2）、怎样使用

有两个命令可以生成RDB文件，SAVE、BGSAVE 。

a）、SAVE命令会阻塞服务器进程，是在主进程中创建RDB文件，会阻塞 其他的客户端请求。

b）、BGSAVE命令会在主进程fork出的一个子进程创建RDB文件，不会阻塞 客户端请求。

c）以上两个指令是在redis-cli客户端直接执行命令时保存RDB文件，还可以设置SAVE命令配置，redis进行自动保存RDB文件。

1. save 60 100 #60秒内有100次修改，redis就会自动保存RDB文件  
2. save 300 10 #300秒内有10次修改，redis就会自动保存RDB文件  
3. ....  

    可以设置多个命令，只要触发一个save命令条件就会自动保存RDB文件。

    这里设置的SAVE命令，redis其实内部是调用BGSAVE命令进行子进程创建RDB文件，确保redis主进程不会受到阻塞，可以继续处理客户端的读写请求。

实际运用：

要根据场景来设定，但是一定要设置。

a）、如果本身redis数据库读大于写，则设置的保存时间长久一些，不妨设置为一个小时才触发一次创建RDB。

b）、如果redis数据库写比较多，而且数据比较敏感，可以设置时间短暂一些，5分钟或者2分钟就保存一次。

c）、数据本身比较敏感，需要进行主从备份，而主从备份依赖原理就是主redis数据库保存RDB时，才会触发同步从redis数据库，这时也响应的设置时间短暂一些。

 

 （3）、原理

 

注意事项代码

1. 注意事项：在执行fork是时候操作系统（类Unix操作系统）会使用写时复制（copy-on-write）策略，即fork函数发生的一刻，父进程和子进程共享同一块内存数据，当父进程需要修改其中的某片数据（如执行写命令）时，操作系统会将该片数据复制一份以保证子进程不受影响，所以RDB文件存储的是执行fork操作那一刻的内存数据。所以RDB方式理论上是会存在丢数据的情况的( fork之后修改的的那些没有写进RDB文件 )。  

 

b）、RDB需要经常调用fork()子进程来持久化到磁盘。如果数据集很大的话，fork()比较耗时，结果就是，当数据集非常大并且CPU性能不够强大的话，Redis会 停止服务客户端几毫秒甚至一秒 。AOF也需要fork()，但是你可以调整多久频率重写日志而不会有损(trade-off)持久性(durability)。 

a)、首先在配置文件中开启AOF

 

        从上面的流程我们能够看到，RDB和AOF操作都是顺序IO操作，性能都很高。而同时在通过RDB文件或者AOF日志进行数据库恢复的时候，也是顺序的读取数据加载到内存中。所以也不会造成磁盘的随机读。

    通常来说，我们应该同时使用这两种持久化方法。在实际配置中，最好两者结合，AOF保证数据不会丢失，RDB进行备份数据以及提供少延迟的主从复制功能。        
   如果可以接受灾难时有几分钟的数据丢失，可以只单独使用RDB。     
   单独使用AOF也并不好，因为时常进行RDB快照非常方便于数据库备份，启动速度也较之快，还避免了AOF引擎的bug。 
    基于这些原因，redis可能会统一AOF和RDB为一种单一的持久化模型(长远计划)。