Redis 序列之二——Redis的持久化

lidonghe

　　Redis是一个支持持久化的内存数据库，也就是说redis需要经常将内存中的数据同步到磁盘来保证持久化。redis支持两种持久化方式，一种是 Snapshotting（快照，默认方式），另一种是Append-only file（aof，文件追加）的方式。
　　（一）Snapshotting（快照）
　　这种方式是就是将内存中数据以快照的方式写入到二进制文件中，默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。我们可以配置redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置：
　　save 900 1   #900秒内如果超过1个key被修改，则发起快照保存 ；
　　save 300 10  #300秒内容如超过10个key被修改，则发起快照保存 ；
　　save 60 10000  #60秒内如果发生超过10000个key被修改，则发起快照保存。
　　下面介绍详细的快照保存过程：
　　1. redis调用fork命令，生成一个子进程。 
　　2.父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copy on write)，父子进程会共享相同的物理页面，当父进程处理写请求时，os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。 
　　3.当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。
　　client也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有 client的请求，这种方式会阻塞所有client请求。所以不推荐使用。另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。另外由于快照方式是在一定间隔时间做一次的，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改。如果应用要求不能丢失任何修改的话，可以采用aof持久化方式。
　　（二） Append-only file（aof，日志追加）
　　aof 比快照方式有更好的持久化性，是由于在使用aof持久化方式时，redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改，不过我们可以通过配置文件告诉redis我们想要通过fsync函数强制os写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次）：
　　appendonly  yes  //启用aof持久化方式  
　　appendfsync always    //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
　　appendfsync everysec  //默认方式，每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐 
　　appendfsync no   //完全依赖os，性能最好，但持久化没保证