Redis 持久化技术

前言

redis是一个key-value键值对数据库，也是一个内存型数据库。所以，当内存断电后，数据就会全部消失。redis提供了两种持久化方式来保存数据，一种是RDB，一种是AOF。

RDB方式

RDB方式其实就是以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。它可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置：

save 900 1  #900秒内如果超过1个key被修改，则发起快照保存
save 300 10 #300秒内容如超过10个key被修改，则发起快照保存
save 60 10000 #60秒内如超过10000个key被修改，则发起快照保存

Redis借助了fork命令的copy on write机制。
其持久化过程如下：
1. redis调用fork,现在有了子进程和父进程。
2. 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。（所以此时修改不会在新的快照文件里）
3. 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出（fork一个进程入内在也被复制了，即内存会是原来的两倍）。

优点：
1. 整个数据库中只有一个备份文件
2. 使用copy-on-write的方式，只需要fork出一个线程出来进行save操作，性能相对较好。
缺点：
1. 在还没有触发save操作时，服务器发生宕机，则之前的写操作会丢失。

AOF方式

AOF 比快照方式有更好的持久化性，是由于在使用AOF持久化方式时，redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。AOF文件是一个追加写入的日志文件。与一般数据库不同的是，AOF文件是可识别的纯文本，它的内容就是一个个的Redis标准命令。下面是它的配置方式

appendonly yes           #启用aof持久化方式
# appendfsync always   #每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
appendfsync everysec     #每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
# appendfsync no    #完全依赖os，性能最好,持久化没保证

AOF在持久化时，会按照配置在文件后面追加内容。所以，当执行incr test命令100次，文件中必须保存全部的100条命令。这样会使得文件冗余且庞大。Redis提供了一个rewrite机制，使用bgrewriteaof命令，来重写AOF文件。下面是rewrite过程：
1. redis调用fork ，现在有父子两个进程
2. 子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
3. 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
4. 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
5. 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。

优点：
1. 具有更好的持久化能力，保证数据丢失在1秒之内
2. 在append过程中，服务器发生宕机，可以使用redis-check-aof工具来解决一致性问题
3. 如果日志过大，Redis可以自动启用rewrite机制，因此在进行rewrite切换时可以更好的保证数据安全性。
缺点：
1. AOF文件相对来说比较庞大，加载AOF文件时比RDB慢
2. AOF在执行效率上比RDB慢

参考博客：
1.http://blog.csdn.net/freebird_lb/article/details/7778981
2.http://blog.csdn.net/yinxiangbing/article/details/48627997
3.http://www.cnblogs.com/Fairy-02-11/p/6182478.html
4.http://www.iteye.com/news/24675