redis--RDB持久化--AOF持久化

Redis是一个内存数据库，如果不想办法将内存上的数据库保存起来，那么当进程退出的时候，数据库也就为空了，为了解决这个问题，提出了，RDB持久化功能，AOF持久化功能；
一、RDB持久化
1、RDB是一个经过压缩的二进制文件，通过保存数据库中的键值对来记录数据库状态；
2、RDB文件的创建与载入
有两个Redis命令可以用于生成RDB文件：SAVE、BGSAVE
SAVE–会阻塞服务器进程，知道RDB文件创建完毕，在服务器阻塞期间，不能处理客户端的任何命令请求；
BGSAVE–会派生出一个子进程，然后由子进程负责创建RDB文件，服务器进程会继续处理客户端的命令请求；
3、AOF文件的更新频率通常比RDB文件的更新频率高，所以，如果服务器开启了AOF持久化功能，那么服务器优先使用AOF文件还原数据库；
二、AOF持久化
1、AOF持久化是通过保存Redis服务器所执行的写命令来记录数据库的状态；
2、执行AOF持久化的功能的命令为BGREWRITEAOF；
3、AOF持久化的实现：命令追加、文件写入、文件同步；
<1>命令追加
当AOF持久化功能处于打开状态时，服务器在执行完一个写命令之后，会以协议格式将被执行的写命令追加到服务器状态的aof_buf缓冲区的末尾。
<2>AOF文件的写入与同步
客户端每执行一条写命令，就将这条写命令以协议格式追加写入到aof_buf缓冲区中，当AOF有个属性标记，距离上一次已经有1秒了，那么服务器会先将aof_buf中的内容写入到AOF文件中，然后再对AOF文件进行同步；
4、AOF文件的载入与数据还原
当服务器重新启动的时候，需要将AOF中的写命令执行一遍，来恢复数据库；服务器是通过创建了一个伪客户端来执行这些写命令，因为只有客户端可以执行这些写命令；
5、AOF重写
AOF持久化是将所有的写命令进行保存，那么随着时间的推移，AOF文件会持续膨胀；如果不加以控制的话，当进行数据库的恢复的时候，读取AOF文件，会使得服务器的性能降低，所以就有了AOF重写功能；通过AOF重写功能，Redis可以创建一个新的AOF文件，将旧的AOF文件中冗余的写命令进行优化，合并，然后写入到新的AOF文件中；最后用新的AOF文件替换旧的AOF文件。在生成新的AOF文件时，我们是通过遍历数据库来生成的；
AOF重写是通过一个进程完成的，当子进程在进行AOF重写期间，服务器还在处理客户端的请求，而新的命令可能会对现有的数据库状态进行修改，所以这些新的请求是放在AOF重写缓冲区中的；当新的AOF文件生成以后，然后将AOF重写缓冲区的数据加到新的AOF文件；
三、两种持久化的优缺点
1、RDB的优点
<1>RDB是一种表示某一个时间点的Redis数据的紧凑文件，RDB比较适合与做备份，可以每隔一小时进行备份，或者备份前30天等；
<2>RDB非常适合灾难恢复，作为一个紧凑文件，可以被传输到其它的数据中心；
<3>RDB在重启保存了大数据集的实例时比AOF要快。
2、RDB的缺点
如果发生宕机的情况，RDB可能会导致部分数据丢失；
3、AOF的优点
<1>AOF的更新频率要比RDB的快；
<2>AOF文件是一个追加文件，所以在发生宕机，恢复的时候，不需要对数据进行定位；
<3>当AOF文件变大的时候，可以执行重写的功能，重写是绝对安全的；
<4>AOF文件中保存的是写操作的一个一个操作，易于理解和解析；
4、AOF的缺点
<1>对于同样的数据集，AOF文件通常要比RDB大一些；
<2>AOF可能比RDB慢；
四、该如何选择
一般来说,如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。如果你非常关心你的数据,但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。有很多用户都只使用 AOF 持久化， 但我们并不推荐这种方式： 因为定时生成 RDB 快照（snapshot）非常便于进行数据库备份， 并且 RDB 恢复数据集的速度也要比 AOF 恢复的速度要快， 除此之外， 使用 RDB 还可以避免之前提到的 AOF 程序的 bug 。因为以上提到的种种原因， 未来我们可能会将 AOF 和 RDB 整合成单个持久化模型。 （这是一个长期计划。）

参考：http://blog.csdn.net/jackpk/article/details/30073097