understanding redis internal

friht

　　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