redis持久化的几种方式

前言：
　　redis是一种高级的key-value数据库，它跟memcached类似，但是redis可以持久化，而且支持的数据类型很多，有字符串（String）,哈希（hash）,列表（list）,集合（set）,有序集合（sorted set）。支持在服务器端集合的并，交和补集等，还支持多种排序功能等，所以redis也可以被看成一个数据结构的数据库。
　　redis所有的数据都存储在内存中，然后不定期的通过异步方式将数据保存在磁盘上（RDB半持久化模式），也可以把每次的数据变化都写入到append only file()aof文件中（全持久化模式）。如果没有配置持久化，redis重启后，内存中的数据就会丢失，于是我们需要开启redis持久化的功能，将数据保存在磁盘上，当redis重启后，将从磁盘恢复数据.
　　以下介绍redis两种持久化方式的区别和优缺点：

1.区别：

RDB持久化是在指定的时间间隔内将内存中的数据集快照写入到磁盘，实际操作时fork一个子进程，先将数据写入一个临时文件，写入成功之后，在替换掉之前的文件，用二进制压缩存储。

RDB命令保存数据的方式（配置文件建文末）
　　保存RDB数据的命令有两种，一个是save，一个是bgsave，一般用的都是bgsave命令。
save命令
　　save命令会阻塞redis服务器的进程，直到RDB文件创建完，在该期间，redis不能处理任何的命令请求，这就是save命令最大的缺陷。
bgsave命令
　　与save命令不同的是，bgsave在生成RDB文件时，会派生出一个子进程，子进程负责创建RDB文件，在此期间，主进程和子进程是同时存在的，因此不会阻塞redis服务器进程。
（可用lastsave命令查看生成RDB文件是否成功）

AOF持久化是以日志的形式记录服务器每一次的写，删除操作，查询操作不会记录，以文本的形式记录，可以打开看到详细的操作记录。

aof文件生成机制：

aof文件生成过程分为3个步骤：文件写入，文件同步。
　　A.redis打开aof持久化功能之后（见后面配置），redis执行完一个写命令之后，调用file.write()方法，把执行的命令追加到redis内部aof_buf的缓冲区末尾。
　　B.对于操作系统来说，调用fsync函数，将AOF文件同步到硬盘。
　　
aof重写：
　　redis不断的将写命令保存到aof中，导致aof的体积不断的增大，当aof越来越大，导致aof文件恢复起来速度也比较慢，aof的重写，一个方式用户可以向redis发送bgrewriteaof命令，这个命令会通过一出AOF文件中的冗余命令来重写AOF文件，使得AOF文件变的尽可能的小。
　　bgrewriteaof的工作原理和BGSAVE工作原理相似，redis会建一个子进程，然后由子进程负责对AOF进行重写（也会存在因为创建子进程而导致的性能问题和内存占用问题）。
　　重写的方式
　　1.手动发送bgrewriteaof命令
　　
　　2.aof重写的配置

no-appendfsync-on-rewrite no         #设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，设置为yes,可以解决在rewrite期间主进程阻塞的问题
auto-aof-rewrite-percentage 100      #当前写入日志文件的大小超过上一次rewrite之后的文件大小的百分之100时就是2倍时触发Rewrite
auto-aof-rewrite-min-size 64mb       #文件的最小体积

2.优缺点

RDB优势：
　　1)如果采用这种方式，那么整个RDB数据库只包含一个文件，这对于文件备份而言是非常完美的，比如，你可能打算每小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一单系统出现灾难性的故障，可以非常容易的进行恢复。
　　2）对于灾难恢复而言，RDB是一个非常不错的选择，因为我们可以非常轻松的将一个单独的文件压缩之后转移到其他存储介质上。
　　3）性能最大化。对于redis服务进程而言，在开始持久化时，它只需要fork出一个子进程,之后再由子进程完成持久化工作，这样也就避免了服务进程的IO操作。
　　4）相对于aof而言，如果数据量大的话，RDB的启动效率相对较高。
RDB劣势：
　　1）如果想要保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不合适，因为系统一旦在下一次持久化之前宕机，此前没来得及写入磁盘的数据将会丢失。
2）由于RDB是fork出子进程来协助完成数据的持久化工作的，当redis内存占用量较大时，或者redis中剩余的内存空间不足时，那么创建子进程和生成rdb文件会占用大量的系统空间和处理时间，redis的性能会大大降低，对redis处理正常的客户端请求造成很大的影响。
3）创建子进程也会占用内存。

AOF优势：
　　1）AOF方式可以带来更高的数据持久性。redis中提供了3中同步策略，即每秒同步，每修改同步和不同步。
事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，就是由操作系统决定何时同步到硬盘。
　　2）由于该机制对日志文件的写入是append模式，因此即使在写入过程中出现宕机，也不会破坏日志文件中已经存在的内容。而如果本次操作只写入了一半的数据就出现了系统崩溃的问题，不用担心，在redis下次启动之前，我们可以通过redis-check工具来帮我们解决数据一致性问题。
3）AOF文件是一个用于记录所有修改操作的格式清晰，易于理解的日志文件。事实上，我们也可以通过该文件完成数据的重建。

AOF劣势：
　　1）对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快，并且占用硬盘空间。
　　2）根据同步策略不同，AOF在运行效率上往往低于RDB，总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

常用配置：
RDB持久化配置

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1              #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10            #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000        #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

AOF持久化配置

appendonly yes                                     #是否打开aof持久化方式，默认是关闭：no
appendfilename "appendonly.aof"        			   #aof文件名称
appendfsync everysec                               #同步方式

在Redis的配置文件中存在三种同步方式，它们分别是：

appendfsync always   　 　 #每次有数据修改发生时都会同步到硬盘。

appendfsync everysec 　 　#每秒钟同步一次硬盘，该策略为AOF的缺省策略。

appendfsync no          #让操作系统决定何时同步到硬盘。

什么情况下会fork子进程？

Master首次向slave同步数据，当master收到slave的syn请求，会fork一个子进程，将内存数据存储到文件上，然后再同步到slave。
　　
　　AOF重写，重写并不会读AOF文件，而是直接使用内存中的数据，并归档日志。
　　
　　持久化很容易造成阻塞，不管是AOF rewrite，还是RDB bgsave，都有可能会出现阻塞，原因是一般情况下，Redis服务设置了appendfsync everysec, 主进程每秒钟便会调用fsync(), 将数据写到存储硬件里. 但由于服务器正在进行大量IO操作, 导致主进程fsync()/操作被阻塞, 最终导致Redis主进程阻塞.解决方案就是“no-appendfsync-on-rewrite yes”

思考：aof重写 auto-aof-rewrite-percentage 100 #当前写入日志文件的大小超过上一次rewrite之后的文件大小的百分之100时就是2倍时触发Rewrite，如果是第一次重写，没有上次rewrite,100这个值怎么判断？

http://blog.csdn.net/jackpk/article/details/30073097

http://www.jb51.net/article/65264.htm