understanding redis internal
redis 持久化有2种方式，定时快照与append only1. 定时快照实现方式：
在上一篇启动流程中提到过，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
页:
[1]