understanding redis internal - 持久化机制

redis 持久化有2种方式，定时快照与append only

 

  1. 定时快照实现方式：

     在上一篇启动流程中提到过，redis启动后有一个定时任务serverCron 每100毫秒执行一次，定时快照就是      在这个任务中执行的，代码如下：

     time_t now = time(NULL);

     for (j = 0; j < server.saveparamslen; j++) {

        struct saveparam *sp = server.saveparams+j;

        if (server.dirty >= sp->changes && now-server.lastsave > sp->seconds) {

            rdbSaveBackground(server.dbfilename);

            break;

          }

     }

   saveparam实际对应的就是配置文件中的save指令，对应时间和改变次数

     save 900 1

     save 300 10

     save 60 10000

    对应结构体定义：

    struct saveparam {

      time_t seconds;

      int changes; 

    }

   server.dirty保存的是上一次持久化后，新产生的变化数量

   可以看到只要配置中的任何一个save指令生效：即超过给定时间且发生了给定的changes，则进行持久化

   再看下rdbSaveBackground函数实现：

   if ((childpid = fork()) == 0) {

        //child

        rdbSave(filename);

        ...

    } else {

       //parent

       server.bgsavechildpid = childpid;

       ... 

    }

    也就是说所说的后台快照进程实际是由主进程fork出来的子进程完成的，由于fork子进程使用的是copy on     write机制，所以子进程可以读取主进程当前的内存空间进行dump工作

    对于子进程rdbSave实际就是把快照内存的所有db的dict数据结构遍历，然后依次写入一个叫

    temp-<child_pid>.rdb的文件中，写完后，rename替换现有rdb文件

    对于主进程要保存快照子进程的pid,之后通过wait系统调用获得子进程退出事件

    主进程在获得快照子进程结束信息后，会调用一个backgroundSaveDoneHandler（）函数

    清除一些标志变量和临时dump文件 temp-<child_pid>.rdb

    backgroundSaveDoneHandler最后还要做一件很重要的事，调用updateSlavesWaitingBgsave（）

    实际作用和redis的复制相关，回头来叙述这个

  2. append only方式

    

    这种方式实际是任何写入操作都会进行持久化，类似于mysql的binlog方式，优缺点大家可以自己理解了

    从代码上可以看到，实际reids接受到client的消息包，解析完后，会查找一个叫cmdTable的结构体数组，     里面存放，对应命令的回调函数，这段代码实际参考call（）函数

        

      static void call(redisClient *c, struct redisCommand *cmd) {

           long long dirty;

           dirty = server.dirty;

           cmd->proc(c);

           dirty = server.dirty-dirty;

           if (server.appendonly && dirty)

                feedAppendOnlyFile(cmd,c->db->id,c->argv,c->argc);

           ...

       }

      cmd->proc实际是调用客户端发来命令对应的回调函数，之后根据命令类型重新赋值dirty,只要有新的        changes就append到aof文件中

      当然redis还提供一些命令可以手工对redis进程持久化操作，比如aof文件过大，可以手工发送rewrite给       服务器

      

      另外需要说明的是：redis的replication实际依赖的是第一种方式，内存快照来实现复制功能的，后续详       细说明

     

   结论：

      1. 内存快照持久化方式，dump数据时不影响redis服务其它的request，但重启会丢失部分数据

      2. aof方式保证不会丢失数据，但同样应该会损失部分性能，不过append only这种方式因为一直是顺序          写入，所以影响应该不是很大

      具体选用哪一个还需要根据业务场景选择

转：http://blog.sina.com.cn/s/blog_6a0c5f190100obld.html