阅读思路

阅读源码的时候应该抓住主干,然后再去各个分支详细分析(个人鄙见)。所以我个人认为redis的启动流程应该是这套源码的主干,所以我先从启动流程下手。对于分析我大致讲个原理,具体详细注释请参照我提交的注释版redis,我在文章中就不再贴源码逐行解释了。

从自己的知识积累出发,先自己预想了下,作为一个服务该有的启动流程。

读取配置->初始化参数->开始网络监听->不断处理网络任务

源码分析

首先查找redis的main函数,不难查找,我们在redis.c这个文件中找到了main函数

我们这里列出main函数里面主要的几个函数,以下所列函数是按它们在main函数里面的执行顺序。(我们主要分析的是普通节点,哨兵节点的逻辑不在范围内)

//--打散argv和environ所存储内容的空间
spt_init(argc, argv);
//--主要在初始化全局的server对象中的各个数据成员
initServerConfig();
//--继续初始化全局的server对象,并在里面初始化了全局的shared对象
//--监听端口和uinx socket文件
//--启动bio线程
//--lua环境
initServer();
//--检查系统的THP和overcommit_memory
linuxMemoryWarnings();
//--检查tcp_backlog和系统的somaxconn参数值
checkTcpBacklogSettings();
//--根据RDB或者AOF文件加载旧数据,优先AOF文件
loadDataFromDisk();
//--进入事件循环处理
aeMain(server.el);

函数分析

  • spt_init()

    redis一开始就把agrv所存储的对象都打散开,是为了后面修改程序名字做铺垫,那为什么改个程序名要这 样大费周折呢,那是因为agrv是连续存储的。具体一些知识点我网上找了个资料可以参考下。

    http://blog.csdn.net/hengshan/article/details/7835981

  • linuxMemoryWarnings()

    redis启动前检测当前系统环境对于内存申请的策略,主要是检查系统里面的/proc/sys/vm/overcommit_memory的文件内容,里面的取值

    0 -> 申请的虚拟内存大小大于现有的物理内存时,返回失败

    1 -> 忽视现有的物理内存,立即分配虚拟内存,当触发缺页而物理内存不足时可能会被oom进程杀死

    2 -> 每次申请都根据现有的物理内存计算出一个阈值,然后跟这个阈值做比较来判断是否允许本次申请

    参考资料:http://blog.chinaunix.net/uid-20671208-id-4440244.html

    当取到的值为0时,redis会打出警告信息。

  • checkTcpBacklogSettings()

    redis启动前进行端口的监听队列的长度检查,通过检查系统的/proc/sys/net/core/somaxconn文件的内容,对于监听队列的长度redis默认是511,由这个值REDIS_TCP_BACKLOG来定义。当取到的值小于server.tcp_backlog,redis会打印出警告信息。

    参考资料:http://blog.csdn.net/taolinke/article/details/6800979

以上几个函数我觉得有一些系统知识点的我罗列出来,具体逻辑还是要详见文章开头的源码,后面重点讲讲 initServer()aeMain()这两个函数,我认为是整个启动流程的重点。