Redis的持久化

Redis是一个基于内存的非关系型数据库，也就是说，基于内存意味着：一旦服务器断电或者出现其他故障，存储在内存中的数据就会丢失。为了安全，Redis提供了持久化这个机制进行保障，简单来说，持久化就是将存储在内存中的数据转存到硬盘上。这样服务器重新启动时，就可以将数据从硬盘上恢复。

Redis提供了两种持久化方式：RDB和AOF。

RDB方式

快照模式，定期把内存中当前时刻的数据保存到磁盘，这是Redis默认支持的持久化方案。

简单来说，RDB是指将某个时刻的内存数据存储到本地磁盘上一个叫做 dump.rdb 的文件中。它是一种快照存储持久化方式，在Redis服务启动的时候，会从该文件中恢复数据。 一般有两种方式开启RDB持久化：配置文件和Redis命令

（默认下，持久化到dump.rdb文件，并且在redis重启后，自动读取其中文件，据悉，通常情况下一千万的字符串类型键，1GB的快照文件，同步到内存中的 时间是20-30秒）

bgSave则是调用Fork,产生子进程，父进程继续处理请求。子进程将数据写入临时文件，并在写完后，替换原有的.rdb文件。Fork发生时，父子进程内存共享，所以为了不影响子进程做数据快照，在这期间修改的数据，将会被复制一份，而不进共享内存。所以说，RDB所持久化的数据，是Fork发生时的数据。在这样的条件下进行持久化数据，如果因为某些情况宕机，则会丢失一段时间的数据。如果你的实际情况对数据丢失没那么敏感，丢失的也可以从传统数据库中获取或者说丢失部分也无所谓，那么你可以选择RDB持久化方式。

再谈一下配置文件的策略，实际上它和bgsave命令持久化原理是相同的。

这是配置文件默认的策略，他们之间的关系是或，每隔900秒，在这期间变化了至少一个键值，做快照。或者每三百秒，变化了十个键值做快照。或者每六十秒，变化了至少一万个键值，做快照。

说白了save 900 1的意思是900秒内，如果大于一个key被修改，900秒后，这些数据将被保存，save 300 10的意思是300 秒内，如果大于十个key被修改，300 秒后，这些数据将被保存，save 60 10000的意思是60 秒内，如果大于一万个key被修改，60 秒后，这些数据将被保存。

AOF方式

AOF持久化的原理是：记录下客户端对服务器的每一次写操作，并将这些写操作存进 appendonly.aof 文件中，在Redis服务器重启时，加载并执行这些写操作，以此来恢复数据。
我们同样可以在Redis配置文件中进行AOF配置。

appendonly no 表示AOF持久化是关闭的，该为也是开启，开启AOF持久化后，你所执行的每一条指令，都会被记录到appendonly.aof文件中。但事实上，并不会立即将命令写入到硬盘文件中，而是写入到硬盘缓存，在接下来的策略中，配置多久来从硬盘缓存写入到硬盘文件。所以在一定程度一定条件下，还是会有数据丢失，不过你可以大大减少数据损失。

配置选项：

1、appendfsync no

当设置appendfsync为no的时候，Redis不会主动调用fsync去将AOF日志内容同步到磁盘，所以这一切就完全依赖于操作系统的调试了。对大多数Linux操作系统，是每30秒进行一次fsync，将缓冲区中的数据写到磁盘上。

2、appendfsync everysec

当设置appendfsync为everysec的时候，Redis会默认每隔一秒进行一次fsync调用，将缓冲区中的数据写到磁盘。但是当这一 次的fsync调用时长超过1秒时。Redis会采取延迟fsync的策略，再等一秒钟。也就是在两秒后再进行fsync，这一次的fsync就不管会执行多长时间都会进行。这时候由于在fsync时文件描述符会被阻塞，所以当前的写操作就会阻塞。

所以，结论就是：在绝大多数情况下，Redis会每隔一秒进行一次fsync。在最坏的情况下，两秒钟会进行一次fsync操作。

这一操作在大多数数据库系统中被称为group commit，就是组合多次写操作的数据，一次性将日志写到磁盘。

3、appednfsync always

当设置appendfsync为always时，每一次写操作都会调用一次fsync，这时数据是最安全的，当然，由于每次都会执行fsync，所以其性能也会受到影响

建议采用 appendfsync everysec（缺省方式）
　　
Redis也允许我们同时使用两种方式，再重启redis后会从aof中恢复数据，因为aof比rdb数据损失小嘛。也就是快照模式可以和AOF模式同时开启，互补影响.

区别和深入理解

RDB每次进行快照方式会重新记录整个数据集的所有信息。RDB在恢复数据时更快，可以最大化redis性能，子进程对父进程无任何性能影响。

AOF有序的记录了redis的命令操作。意外情况下数据丢失甚少。他不断地对aof文件添加操作日志记录，你可能会说，这样的文件得多么庞大呀。是的，的确会变得庞大，但redis会有优化的策略，比如你对一个key1键的操作，set key1 001 , set key1 002, set key1 003。那优化的结果就是将前两条去掉咯，那具体优化的配置在配置文件中对应的是

前者是指超过上一次aof重写aof文件大小的百分之多少，会再次优化，如果没有重写过，则以启动时为主。后者是限制了允许重写的最小aof文件大小。bgrewriteaof命令是手动重写命令，会fork子进程，在临时文件中重建数据库状态，对原aof无任何影响，当重建旧的状态后，也会把fork发生后的一段时间内的数据一并追加到临时文件，最后替换原有aof文件，新的命令继续向新的aof文件中追加。