redis持久化

官方文章http://redis.io/topics/persistence

redis持久化主要分为两种RDB和AOF

      Redis支持2种持久化策略：snapshot方式和commandlog方式，前者通过将当前内存数据快照周期性写入RDB文件来实现；后者通过在log中记录Redis进程收到的写操作来实现，下次Redis重启时，回放commandlog来恢复数据状态。
        根据实际需求，用户可以选择完全禁用持久化，也可以在同一个Redis实例中同时启用RDB和AOF。
        特别注意：如果部署方式为主从，则不同实例的持久化时机最好错开！避免master和slaves同时进入后台持久化，这可能会降低系统的性能。

1. RDB相关配置
        1) databases
        配置db文件的数目，可以用select <dbid>指令为每个连接指定后续持久化时的db文件，新连接默认均使用db 0
        2) save
        SNAPSHOTTING的持久化方式有多种save策略可供选择，而且支持混用，例如：
          save 900 1
          save 300 100
          save 60  10000
        上述配置的效果是：snapshotting会在3个条件中的任何一个满足时被触发：a. 900s内至少1个key有变化；b. 300s内至少100个key有变化；c. 60s内至少有10000个key有变化
        save条件被触发时，Redis通过fork子进程，由子进程在后台实现异步dump磁盘。根据fork的写时复制策略，若持久化过程中出现很多写入请求，在最坏的情况下，需要的内存是当前数据集所占内存的2倍。
        备注1：上述配置的3个触发条件其实是逐次加强的，哪个条件先满足就先触发那个save策略。
        备注2：如果业务不需要持久化或不需要RDB方式的持久化，可以通过注释掉save配置项来实现
        3) stop-writes-on-bgsave-error
        指定Redis在后台dump磁盘出错时的行为，默认为yes，表示若后台dump出错，则RedisServer拒绝新的写入请求，通过这种方式来引起用户警觉，避免因用户未发现异常而引起更大的事故。
        4) rdbcompression
        RDB文件是否压缩存储，若为yes，会在压缩时消耗一点CPU，但省磁盘空间。
        5) rdbchecksum
        RDB文件是否需要CRC64校验, 若为yes,会在生成RDB文件后计算其CRC64并将结果追加至文件尾，同样，Redis启动Load RDB时，也会先计算该文件的CRC64并与dump时的计算结果对比。
        好处：可以严格保证RDB的完整性及安全性
        代价：会在dump或load时损失10%的性能。如果要最大化Redis的性能，这个配置项应该用no关掉
        6) dbfilename
        指定RDB文件名，默认为dump.rdb 
        7) dir
        指定RDB文件存放目录的路径，若包含多级路径，则相关父路径需事先mkdir出来，否则启动失败。

2. AOF相关配置
        默认情况下，Redis以写RDB文件的方式持久化数据（除非用户主动禁用RDB方式的持久化）。若Redis进程挂掉或机器掉电，则上次save完成时刻至故障时刻这段时间内的新数据会丢失。AOF的引入可以将数据损失的程度减少到1秒或1条写入指令。
        1) appendonly
        配置是否启用AOF持久化，默认为no
        2) appendfilename
        指定aof文件名，默认为appendonly.aof 
        3) appendfsync
        配置aof文件的同步方式，Redis支持3种方式：
         a. no => redis不主动调用fsync，何时刷盘由OS来调度；
         b. always => redis针对每个写入命令均会主动调用fsync刷磁盘；
         c. everysec => 每秒调一次fsync刷盘。
        用户可以根据业务对数据的敏感性选择合适的同步策略。
        4) no-appendfsync-on-rewrite
        指定是否在后台aof文件rewrite期间调用fsync，默认为no，表示要调用fsync（无论后台是否有子进程在刷盘）。备注：Redis在后台写RDB文件或重写afo文件期间会存在大量磁盘IO，此时，在某些linux系统中，调用fsync可能会阻塞。
        5) auto-aof-rewrite-percentage
        指定Redis重写aof文件的条件，默认为100，表示与上次rewrite的aof文件大小相比，当前aof文件增长量超过上次afo文件大小的100%时，就会触发background rewrite。若配置为0，则会禁用自动rewrite。
        6) auto-aof-rewrite-min-size
        指定触发rewrite的aof文件大小。若aof文件小于该值，即使当前文件的增量比例达到auto-aof-rewrite-percentage的配置值，也不会触发自动rewrite。即这两个配置项同时满足时，才会触发rewrite。

3. 需要明确的问题
        1）若同时启用RDB和AFO两种持久化方式，则Redis Server启动时，会加载AOF文件以重建数据集，因为AOF可以保证数据是相对最完整的。
        2）关于RDB和AOF各自的优缺点以及用户如何选择合适的持久化策略，可以参考这里。
        3）简言之，若可以忍受数据丢失，只启用RDB即可；若对数据很敏感，可以同时启用RDB和AOF；不建议只启用AOF（注释配置文件的save配置项或通过redis-cli执行save ""），因为一旦如果AOF文件损坏或AOF解析引擎存在bug，整个数据集都无法重建。

http://blog.csdn.net/slvher/article/details/17681823