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同步数据

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