一、概述

     Redis的强大性能很大程度上都是因为数据时存在内存中的，然而当Redis重启时，所有存储在内存中的数据将会丢失，所以我们要将内存中的数据持久化。

Redis支持两种数据持久化的方式: RDB方式和AOF方式。

(1)RDB方式会根据配置的规则定时的将内存中的数据持久化到硬盘上。

(2)AOF则是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

     其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。

     如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。

 

1.RDB方式

     RDB方式的持久化是通过快照的方式完成的。当符合某种规则时，会将内存中的数据全部生成一个副本存储在硬盘上，Redis会在以下几种情况下对数据进行快照:

a: 根据配置的规则自动快照。

b: 用户执行save、bgsave命令。

c: 执行flushall命令。

d: 执行复制(replication)。

(1)根据配置自动快照

     Redis允许用户自定义快照条件，当满足条件时自动执行快照，快照规则的配置方式如下:

 

(2)执行save、bgsave命令

     我们可以手动执行save、bgsave命令主动进行快照操作。

save: 当执行save命令时，Redis同步进行快照操作，期间会阻塞所有来自客户端的请求，所以放数据库数据较多时，应该避免使用该命令；

bgsave: 从命令名字就能看出来，这个命令与save命令的区别就在于该命令的快照操作是在后台异步进行的，进行快照操作的同时还能处理来自客户端的请求。执行bgsave命令后Redis会马上返回OK表示开始进行快照操作，如果想知道快照操作是否已经完成，可以使用lasesave命令返回最近一次成功执行快照的时间，返回结果是一个Unix时间戳。

 

(3)执行flushall命令

     执行FLUSHALL命令时，Redis会清除数据库中的所有数据。

 

(4)执行复制

     当设置了主从模式时，Redis会在复制初始化的时候进行自动快照。

 

2.快照原理

     Redis默认会将快照文件存储在Redis当前进程的工作目录的dump.rdb文件中，可以通过配置文件中的dir和dbfilename两个参数分别指定快照文件的存储路径和文件名。

    

快照执行的过程如下:

(1)Redis使用fork()函数复制一份当前进程(父进程)的副本(子进程)。

(2)父进程继续处理来自客户端的请求，子进程开始将内存中的数据写入硬盘的临时文件。

(3)当子进程写完所有的数据后，用该临时文件替换旧的RDB文件。

     Redis启动时会自动读取RDB快照文件，将数据从硬盘载入到内存，根据数量的不同，这个过程持续的时间也不尽相同，通常来讲，一个记录1000万个字符串类型键，大小为1GB的快照文件载入到内存需要20-30秒的时间。

     对于RDB方式，redis会单独创建(fork)一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。

     如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

     虽然RDB有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是AOF。

 

3.AOF方式

默认情况下，Redis没有开启AOF(append only file)持久化功能，可以通过在配置文件中作如下配置启用：

    

     开启之后，Redis每执行一条写命令就会将该命令写入硬盘中的AOF文件。AOF文件保存路径和RDB文件路径是一致的，都是通过dir参数配置，默认文件名是：appendonly.aof，可以通过配置appendonlyfilename参数修改。

AOF英文是Append Only File，即只允许追加不允许改写的文件。

     如前面介绍的，AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。

     我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作（如SET等），redis就会被追加到AOF文件的末尾。

     默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。

     如果在追加日志时，恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整，也没有关系，redis提供了redis-check-aof工具，可以用来进行日志修复。

     因为采用了追加方式，如果不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。

     在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性，这点大家可以放心。

     AOF方式的另一个好处，我们通过一个“场景再现”来说明。某同学在操作redis时，不小心执行了FLUSHALL，导致redis内存中的数据全部被清空了，这是很悲剧的事情。不过这也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件还没有被重写（rewrite），我们就可以用最快的速度暂停redis并编辑AOF文件，将最后一行的FLUSHALL命令删除，然后重启redis，就可以恢复redis的所有数据到FLUSHALL之前的状态了。是不是很神奇，这就是AOF持久化方式的好处之一。但是如果AOF文件已经被重写了，那就无法通过这种方法来恢复数据了。

     虽然优点多多，但AOF方式也同样存在缺陷，比如在同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式。

     如果你直接执行BGREWRITEAOF命令，那么redis会生成一个全新的AOF文件，其中便包括了可以恢复现有数据的最少的命令集。

     如果运气比较差，AOF文件出现了被写坏的情况，也不必过分担忧，redis并不会贸然加载这个有问题的AOF文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：

1.备份被写坏的AOF文件。
2.运行redis-check-aof –fix进行修复。
3.用diff -u来看下两个文件的差异，确认问题点。
4.重启redis，加载修复后的AOF文件。