understanding redis internal - 主体结构与启动流程
一. redis的定义
官方wiki对redis的定义是：a disk backed in-memory database
从这个可以理解实际上使用redis的场景应该大部分情况下你的数据集应该是在内存中操作的，同时提供了落地的功能
二. redis 主体框架与启动流程
redis主体上是一个单线程基于事件机制的一个模型，使用了一套事件处理框架 aeEvent，基本上这个东西和libevent做的是相同的工作，提供事件处理机制以及封装不同平台的IO事件模型
redis启动流程大体如下(有兴趣可以参照函数名翻阅源代码，暂时忽略vm选项处理细节)：
initServerConfig() //初始化全局struct server数据结构，给每个成员赋予默认值
loadConfig() //如果指定了配置文件，会读取redis.conf重新赋值给struct server实例
initServer() //初始化其它数据结构，创建db 对应dict数据结构等，bind,listen启动网络服务
initServer函数里最重要的是下面2行代码
aeCreateTimeEvent(server.el, 1, serverCron, NULL, NULL); //添加定时器事件
aeCreateFileEvent(server.el, server.fd, AE_READABLE,acceptHandler, NULL); //添加IO事件
initServer函数在这里向aeEvent 添加了2个事件：
1. 事件启动后的下一毫秒调用 serverCron 函数，
实际这个serverCron在执行完后会被重新设置加入调度事件中，以后每隔100 毫秒执行一次
（这里aeEvent框架使用的是链表来保存定时器事件的，也就是说查找超时事件是O(n)的复杂度，且 处理了一个超时事件后，需要重新定位到队头重新扫描一遍，对比libevent的minheap数据结构 O(1)复杂度应该差一些）
2. 注册网络监听accept 客户端连接事件，客户端连接建立成功后，回调acceptHandler方法
需要说明的是这里只是注册了这个事件并没有真正启动事件处理，对于epoll来说只是调用了 epoll_ctl的add，需要等待调用epoll_wait后才开始调度io事件，所以前面虽然已经调用了socket 的bind,listen,实际上redis还没有准备好提供服务
（这里的网络细节处理实际上是：服务器可以与客户端发来的syn进行tcp的3次握手，但是最后这个 已连接fd会被放入tcp的已完成队列中，等待accept操作来把这个fd取走）
initServer()函数结束后，会根据配置来加载数据文件，如果是第一次启动当然没有这个了
if (server.appendonly) {
if (loadAppendOnlyFile(server.appendfilename) == REDIS_OK) ...
} else {
if (rdbLoad(server.dbfilename) == REDIS_OK) ...
}
根据配置是appendonly的aof文件还是快照保存的rdb文件来加载数据
最后通过aeMain来启动事件处理框架，实际对应网络io api，也就是调用最终的epoll_wait或者select()函 数
整个server启动完毕，可以看到启动后事件框架中主要处理2个事件：
1. redis的网络io accept及读写事件
2. 每隔100毫秒执行一次的定时器事件serverCron
整个流程暂时忽略vm选项，那个处理的细节比较多暂时没梳理清楚，所以先忽略下
三. serverCron定时器事件处理流程
再来看下serverCron这个每100毫秒执行一次的函数都干了什么：
1. 打印非空db的一些信息，log功能
2. 如果当前没有后台运行dump数据保存到文件的进程，则可以根据内存使用情况重新调整hashTables大小
3. 日志输出一些client的连接信息
4. 检测idle的client 连接，关闭idle连接
5. 判断是否有正在进行dump数据到文件的后台进程
如果有判断是否已经结束，进行结束后的一些工作（这个跟replication有关，后续详细说明）
没有则判断是否需要启动新的进程dump数据到文件
6. 处理expired的key
7. vmSwapOut功能，如果启动了vm选项，则判断是否超过vmMaxMemory,如果超过进行value的swap
8. 判断如果server是slave,则连接master,发送sync命令，和master同步数据