Redis持久化

        Redis支持两种方式的持久化，一种是RDB方式，另一种是AOF方式。前者会根据指定的规则“定时”将内存中的数据存储在硬盘上，而后者在每次执行命令后将命令本身记录下来。两种持久化的方式可以单独使用其中一种，但更多情况是将二者结合使用。

一、RDB方式

        RDB方式的持久化是通过快照（snapshortting）完成的，当符合一定条件时Redis会自动将内存中的数据生成一份副本并存储在硬盘上，这个过程即成为“快照”。Redis会在以下几种情况对数据进行快照：

1、根据配置规则进行自动快照；

2、用户执行save或者bgsave命令；

3、执行flushall命令；

4、执行复制（replication）时。

（一）、根据规则配置进行自动快照

        Redis允许用户自定义快照条件，当符合快照条件时，Redis会自动进行快照操作。进行快照的条件可以由用户在配置文件中自定义，由两个参数构成：时间窗口M和改动的键的个数N。每当时间M内被更改的键的个数大于N时，即符合自动快照条件。例如Redis安装目录中包含的样例配置文件中预置的3个条件：

save  900 1 

save 300 10 

save 60 10000

        每条快照条件占一行，并且以save参数开头。同时存在多个条件，条件之间是或的关系。就这个例子而言save  900 1 的意思是在15分钟（900秒）内有一个或者一个以上的键被更改则进行快照。

（二）、用户执行SAVE或BGSAVE命令

        除了让Redis自动进行快照外，当进行服务重启、手动迁移以及备份时我们也需要手动执行快照操作。Redis提供两个命令来完成这一任务。

1、SAVE命令

       当执行SAVE命令时，Redis同步地执行快照操作，在快照执行的过程中会阻塞所有来自客户端的请求。当数据库中的数据比较多时，这一过程会导致Redis较长时间不响应，所以要尽量避免在生产环境使用这一命令。

2、BGSAVE命令

       需要手动执行快照时推荐使用BGSAVE命令。BGSAVE命令可以在后台异步地进行快照操作，快照的同时还可以响应来自客户端的请求。执行BGSAVE后Redis会立即返回OK表示开始执行快照操作，如果想知道快照是否完成，可以通过LASTSAVE命令获取最近一次成功执行快照的时间。

（三）、执行FLUSHALL命令

        当执行FLUSHALL命令时，Redis会清除数据库中的所有数据。需要注意的是，不论清空数据库的过程是否触发了自动快照条件，只要自动快照条件不为空，Redis就会执行一次快照操作。当没有定义自动快照条件时，执行FLUSHALL命令时则不会进行快照。

（四）、执行复制时

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

（五）、快照原理

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

1、Redis使用fork函数复制一份当前进程（父进程）的副本（子进程）；

2、父进程继续接收并处理客户端发来的命令，而子进程开始将内存中的数据写入硬盘中的临时文件；

3、当子进程写入完所有数据后会用该临时文件替换旧的RDB文件，至此一次快照操作完成。

        通过上述过程可以发现Redis在进行快照的过程中不会修改RDB文件，只有快照结束后才会将旧的文件替换成新的，也就是说RDB文件在任何时候都是完整的。这使得我们可以通过定时备份RDB文件来实现Redis数据库备份。RDB文件是经过压缩的二进制格式，所占用的空间会小于内存中的数据大小，更加利于传输。

        Redis启动后会读取RDB快照文件，将数据从硬盘载入内存。根据数据量大小与结构和服务器性能的不同，这个时间也不同。

通过RDB方式实现持久化，一旦Redis异常退出，就会丢失最后一次快照以后更改的所有数据。这就需要开发者根据具体的应用场合，通过组合设置自动快照条件的方式来将可能发生的数据损失控制在能够接受的范围内。

二、AOF方式

        当使用Redis存储非临时数据时，一般需要打开AOF持久化来降低进程中止导致的数据丢失。AOF可以将Redis执行的每一条写命令追加到硬盘文件中，这一过程显然会降低redis的性能，但是大部分情况下这个影响是可以接受的，另外使用较快的硬盘可以提高AOF的性能。

（一）、开启AOF

        默认情况下Redis没有开启AOF方式的持久化，可以通过appendonly参数启用：appendonly yes。 

        开启AOF持久化后每执行一条会更改Redis中的数据的命令，Redis就会将该命令写入硬盘的AOF文件。AOF文件的保存位置和RDB文件的保存位置相同，都是通过dir参数设置的，默认的文件名是appendonly.aof，可以通过appendfilename参数更改。

（二）、AOF的实现

        AOF文件以纯文本的形式记录了Redis执行的写命令，AOF文件的内容正是Redis客户端向Redis发送的原始通信协议的内容。每当达到一定条件时Redis就会自动重写AOF文件，这个条件可以在配置文件中配置：

        auto-aof-rewrite-percentage参数的意义是当目前的AOF文件大小超过上一次重写时的AOF文件大小的百分之多少时会再次进行重写，如果之前没有重写过，则以启动时的AOF文件大小为依据。auto-aof-rewrite-min-size参数限制了允许重写的最小AOF文件大小，通常在AOF文件很小的情况下即使其中有很多冗余的命令我们也并不太关心。除了让redis自动执行重写外，我们还可以主动使用BGREWRITEAOF命令手动执行AOF重写。AOF重写后冗余的命令会被删除。重写的过程只和内存中的数据有关，和之前的AOF文件无关，这与RDB很相似，只不过二者的文件格式完全不同。

（三）、同步硬盘数据

        虽然每次执行更改数据库内容的操作时，AOF都会将命令记录在AOF文件中，但事实上，由于操作系统的缓存机制，数据并没有真正被写入硬盘，而是进入了系统的硬盘缓存。在默认情况下系统每30秒会执行一次同步操作，以便将硬盘缓存中的内容真正写入硬盘，在这30秒的过程中如果系统异常退出则会导致硬盘缓存中的数据丢失。一般来讲启用AOF持久化的应用都无法容忍这样的损失，这就需要redis在写入AOF文件后主动要求系统将缓存内容同步到硬盘中。在redis中我们可以通过appendsync参数设置同步的时机。

        默认情况下redis采用everysec规则，即每秒执行一次同步操作。always表示每次执行写入都会执行同步，这是最安全也是最慢的方式。no表示不主动进行同步操作，而是交由操作系统来做（即每30秒一次），这是最快但是最不安全的方式。一般情况下使用默认值everysec就足够了，既兼顾了性能又保证。

        Redis允许同时开启AOF和RDB，既保证了数据安全又使得备份操作十分容易。此时重启Redis后Redis会使用AOF文件来恢复数据，因为AOF方式的持久化可能丢失的数据更少。